- Email: [email protected]
Configuration
Handbook of Constraint Programming Edited by F. Rossi, P. van Beek and T. Walsh c 2006 Elsevier B.V. All rights reserved
837
Chapter 24
Configuration Ulrich Junker Configuration is the task of composing a customized system out of generic components. This task is of concern to everybody as component-based systems are omnipresent in modern industry. Prominent examples of component-based systems are computers, home cinemas, cars, and trucks. Classic examples are kitchen and furniture that can be assembled from a given catalog of components. As the need for customization is growing, more and more products follow the pattern of a component system. New examples are service packs such as telecommunication offers, loans and insurance products, but also travel packages and other examples from the service industry. Finally, we should not forget componentbased software systems. Components are generic in nature and can be produced in mass, but are destined to support customized solutions. The available components for a given type of system are usually described in the form of a catalog. Each catalog item is a product type and describes the functional and technical characteristics of the component. For example, take a printer component. The function is printing. The functional characteristics include printing quality and support of colors. The technical characteristics include printing type (laser, jet) and printing speed. Whereas the catalog describes the generic knowledge of components, a customer usually has specific requirements for the desired component-based system. For example, the customer wants to set up a home movie studio that allows the filming, editing, and showing of movies and optionally the printing of snapshots and insertion of photos. To match the specific customer requirements, a configuration of the components needs to be determined. A configuration is a set of instances of the available component types that are customized and combined to meet the requirements. A configuration for the home movie studio consists of a video camera with analog output, a video recorder with analog input, and a TV screen. Another configuration consists of a video camera with digital output, a computer with a card for digital video capture, software for video editing, a DVD reader/writer, a printer, and a scanner. The task of finding a suitable configuration encounters several difficulties. Firstly, there can be a huge number of configurations responding to the customer requirements. The
838
24. Configuration
number of alternatives may be large even if a single component needs to be chosen. The customer usually is not satisfied with an arbitrary choice, but has preferences on multiple criteria of the catalog items such as the color or seat material of a desired car. Hence, a configuration problem may correspond to a multicriteria decision-making problem. Normally, a configuration does not consist of a single component, but multiple components. Car configuration problems allow the choice of multiple options that are subject to technical constraints. For example, the choices of a roof rack and of a cabriolet are incompatible. In this case, the configuration problem is a combinatorial problem. In more complex examples such as the configuration of instrumentation and control systems, the number of required components is initially unknown. The problem space of the configuration task then contains a possibly infinite number of candidate configurations. Universally quantified constraints can be used to represent knowledge about unknown parts and we obtain a satisfiability problem in a (decidable) fragment of first-order logic. Finally, a configuration problem can be large in size and involve huge numbers of product types and constraints. Complex configuration problems are, for example, encountered in the engineering and manufacturing departments of the computer and automotive industries, which need to complete customized sales orders by choosing suitable parts from huge catalogs. This situation has led to the development of configurators that do this completion automatically while respecting difficult technical constraints. However, configurators can also support the sales process and assist the user in choosing options while guaranteeing their compatibility. Although the first configurators were based on production rules, Constraint Programming (CP) nowadays appears to be the method of choice for solving diverse forms of configuration problems. CP addresses the complete space of possible configurations, no more and no less. End users can formulate arbitrary requirements without taking the risk that their favorite configurations are forgotten. CP handles the combinatorial aspects of configuration problems. CP is able to discover unforeseen interactions between different components and constraints thanks to propagation, search, and learning algorithms. CP can also profit from existing expertise in solving configuration problems by using it for guiding the search. However, classic CP methods lacked appropriate techniques to represent complex configuration knowledge, to reason about an unknown number of components, to handle user preferences, or to provide explanations when interactive solving ran into failure. Specific research on constraint-based configurators has addressed those points by incorporating techniques from fields such as knowledge representation, theorem proving, and preference handling. This handbook chapter gives a survey of the main techniques. Section 24.1 explains the diversity of configuration problems and extracts specific challenges for CP. Section 24.2 distinguishes different kinds of knowledge used in configuration problems, which can be used to build rather different constraint models as explained in section 24.3. Section 24.4 presents the problem-solving tasks occurring in configuration.
24.1 What Is Configuration? 24.1.1
A Whole Spectrum of Problems
Configuration has been an outgrowth of research on rule-based expert systems. John McDermott [41] used the term configuration for a specific form of a design task [9], where a system was assembled out of predefined components that are connected in predefined
U. Junker
edit system ......... .... .... ...
Home Movie Studio
filming capability editing capability show capability
...
Video Editing software...... ...... ..... Software 1..1
839
... devices ....... ....... ...
edit capacity video file format
... computer ....... ..... ...
0..1 Video Editing System
Device 0..n ... .. ..... ..... ..... .... .... .... .... .... .... .... ....
Camera
1..1
DVD Player
..
... ... disks Computer ............. 0..n
storage capacity
TV
Hard Disk
Figure 24.1: Component types of a home movie studio.
ways. Whereas more innovative design tasks often require a suitable modeling of the physical behavior of components [64], work on rule-based configurators focused on the functional aspects of components. Frayman and Mittal summarized those approaches by a general definition of the configuration task [44] and thus provided a foundation of the field of configuration similar to Reiter’s for the fault diagnosis in technical systems [49]. The essence of this definition is as follows: A configuration problem is characterized by two constituents: 1. A catalog which describes the generic components in terms of their functional and technical properties and the relationship between both. 2. User requirements and user preferences about the functional characteristics of the desired configuration. The configuration task consists of finding the following answer: 1. One or more configurations that satisfy all requirements and that optimize the preferences if those requirements are consistent. 2. An explanation of failure in the other case. A configuration is a set of customized components together with a description of their connections. A component itself is defined by its type, its attributes, and its subcomponents. Attributes may express functional properties such as filming capability or edit capacity in terms of filmed hours (see Figure 24.1). However, attributes may also express technical properties that describe how a given functional property is achieved. For example, the video file format (AVI, MPEG2) used for editing and the storage capacity are technical characteristics. If a given functional property is fulfilled by a single component, then this component is primitive and has no subcomponents. In the movie studio example, a video camera directly realizes the filming functionality. However, a function may also be fulfilled by a combination of components. The combination can be achieved by a composite component that has subcomponents. For example, the storage capacity of a movie studio system may be supplied by a computer as well as the external disks of the computer, which thus all together achieve the required edit capacity. The combination can also be achieved by an architecture that defines how components need to be combined to fulfill the function. For example, the home movie studio may have a video editing system, which consists of a computer, editing software, and other components such as a video capture card and a video
840
24. Configuration
recording facility. This video editing system is not a component that can be chosen from a catalog, but a ‘functional unit’ that describes how other components need to be combined for the purpose of video editing. The general description of the configuration task covers a large spectrum of concrete configuration problems and can be simplified depending on the application domain and the purpose of the configurator. As explained in [28, 51], it is useful to distinguish configuration for sales and configuration for manufacturing and engineering. Sales configurators address the needs of laymen in business-to-customer applications (B2C) or buyers in business-to-business applications (B2B). Components are described in terms of sales categories and correspond to items that customers can order. Their level of detail is much smaller than that of the parts that can be manufactured. The result of the sales configuration can be used as input for a technical configurator that checks whether the ordered system can be produced. The configurator uses existing product models in the form of billof-materials and compatibility tables and chooses a structure and the parts of the product. Whereas sales configurators are highly interactive and user-driven, manufacturing requires configurators that automatically complete given requirements. The structure of a configured system depends on the application domain. A car configuration usually consists of a small number of features. A configured computer is typically described by a small hierarchy of parts. A custom kitchen may have an unbounded number of parts. An instrumentation-and-control system may additionally require that an unbounded number of parts is packed into an unknown number of racks and boards. This difference in structure explains why so many different techniques have been applied to configuration problems. A first survey of configuration techniques given by [51] distinguishes rule-based reasoning [41], model-based reasoning [44], and case-based reasoning for configuration. The model-based branch covers approaches based on description logic [42], constraint programming [43, 59], and resource models [31]. The survey now needs to be completed by approaches based on SAT [55], binary decision diagrams [29], integer programming [62], and also answer-set programming [54]. Furthermore, there have been various attempts to combine several techniques in order to enhance the modeling and solving capabilities of a configurator. The diversity of techniques is confirmed by other surveys [27, 58]. Independent of the problem and the approach, a configurator needs to address the following requirements concerning problem solving: 1. Generation of components to carry out the functional requirements. 2. Reasoning about the interactions of multiple components. 3. Detection of cases where the desired functionality cannot be implemented. A further requirement concerns modeling. The configurator needs to provide a high-level modeling language that allows the configuration expert to model complex systems and to maintain these models. Rule-based approaches represent functional requirements in terms of assertions in the working memory and map them to components through rules. A rule for selecting a component is fired if there is a requirement needing this component. When executed, a rule can generate new components, customize existing components, or add subcomponents. Depending on the context, the same function may be achieved differently, meaning that we obtain multiple rules of the form:
U. Junker
841
if function and context 1 and constraints okay then component 1 ... if function and context m and constraints okay then component n The rule conditions need to check possible interactions with other components and may become very complex. If compatibility constraints between components are changing, then they need to be incorporated into the conditions of multiple rules. This lack of modularity caused a severe maintenance problem in the R1/XCON configurator of DEC computers [41, 4]. Furthermore, rule-based systems usually do not have the capability of detecting cases that cannot be achieved by the given catalog. Nevertheless, rule-based systems may be useful for very simple configuration problems requiring a small number of choices only. Model-based reasoning addresses the deficiencies of rule-based reasoning. Firstly, it separates the problem description from the solving algorithm, thus allowing an analysis of the problem independent of the chosen approach. Secondly, it requires that the problem description is based on a model of the system to be configured. This model consists of decomposable entities and the interactions between these elements. Modularity or composability is thus well-addressed since components can easily be added or removed without changing the whole model. Thirdly, it requires that this problem description is complete and defines a closed space of possible configurations. If no element of this space satisfies the given requirements, then the problem has no solution. Description logic (DL) is well-suited to describe component types and their relations. It organizes components types in a taxonomy. Description logic allows us to define complex types out of primitive types. It is able to detect specialization relations between complex types and to test the consistency of types by a process called classification. Classification can be used to solve configuration problems if the configuration knowledge can be completely expressed in the description logic. In most cases, the expressiveness of the description logic is not sufficient and a rule-based or constraint-based engine is used in addition to deal with complex compatibility and numerical constraints. Such a hybrid approach has, for example, been pursued in the CLASSICS-project [42] and in the PLAKON-project [10]. DL-based configurators have been applied to the configuration of telecommunication equipment [42], elevators [61], passenger cabins in aircrafts [27], and many other systems that have a complex structure. They also address the problem of generating a hierarchy of parts and can exploit this hierarchy for problem decomposition [39]. Resource-based approaches [31] are dedicated to complex equipment configuration problems where components provide and consume given resources. For example, the storage devices of a computer system provide storage capacity, but they consume power and slots. The slots are provided by the racks of the computer system. The purpose of the resource-based configuration process is to bring produced and consumed resources in balance, meaning that the consumed resource does not exceed the produced resource. The process starts from initial resource requirements such as a minimal storage capacity, which are consumed from outside and which need to be produced by generating and customizing suitable parts. The resource-based approach is necessary for many configuration problems, but is not sufficient on its own. As such, it is best integrated with other approaches. Constraint satisfaction problems (CSP) are well-suited to defining a closed space of configurations. They use variables with domains. If the number of variables is fixed, then the space is obtained as the Cartesian product of the domains. Constraints also handle the interaction of multiple components. Compatibility constraints specify which components
842
24. Configuration
can be combined. Aggregation constraints (such as sums) are able to deduce global properties such as the produced or consumed amount of a resource. Variables express the possible choices for fulfilling a functional requirement. Since the choice should only be made if the requirement is present, we obtain a conditional disjunction of the form: if function then component 1 or ... or component n The disjunction is encoded by a variable x having as domain the components that can be chosen. However, this variable should only be introduced if the function is indeed required and this may depend on other choices. Hence, new variables and constraints may be activated or generated during the problem solving. A rule-based constraint engine can add new constraints when executing rules and retract them during search thanks to a truth maintenance system (TMS) [15, 12]. For example, the configurator in [28] is based on a TMS. However, the dynamic nature of configuration problems provides a particular challenge for Constraint Programming approaches that maintain local consistency during search. Mittal and Falkenhainer therefore introduced Dynamic CSPs (now called Conditional CSPs) which have optional variables and constraints. Local consistency algorithms for Conditional CSPs have been elaborated in [43, 52]. Stumptner and Haselb¨ock [60, 59, 17] introduced resource-based reasoning into CP and Mailharro [40] extended it with cardinalitybased reasoning. The CP approach has successfully been applied to the configuration of cars, computers [18], instrumentation and control systems [40], web services [3]. SAT approaches can be seen as a special case of CP. They mainly handle requirement and compatibility constraints, but no numerical constraints such as resource constraints. They have successfully been applied to car configuration [55]. Answer-set programming [54] formulates configuration knowledge through form of default rules, while ensuring functionally well-justified configurations through groundedness conditions [56]. This approach has been applied to software configuration [65]. Interactive sales configurators are simultaneously solving the configuration problems of multiple customers and require rapid response times. As these problems differ only in the requirements, but not in the catalog, preprocessing techniques can be used to compute configurations in advance. For problems involving a fixed number of parts with small finite domains, it may be possible to represent the whole configuration space compactly by a binary decision diagram [29], an automaton [2], or the decomposable negation normal form [11]. Other knowledge-compilation techniques include synthesis trees [63] and clustertrees [14, 46]. All these techniques are compatible with respect to a CP approach. Knowledge compilation has successfully been applied to car configuration problems [29, 46]. CP is well-suited to define a clear configuration space. It ensures composability by treating interactions between arbitrary components and by deriving global properties of sets of components. It also offers a high freedom in modeling and the modeling is completely declarative. Thus, CP meets the requirement for an expressive and maintainable modeling capability that has been stated above. All these advantages made it the method of choice for configuration. However, configuration problems posed several challenges to CP which are summarized in the next sections.
24.1.2
Modeling Challenges for CP
Most applications of Constraint Programming (CP) concern real-world systems that are modeled in an object-oriented way. CP addresses the combinatorial aspect of the applica-
U. Junker
843
tion to be solved. It is often possible to isolate this aspect by generating a constraint model from the given object model. For example, a production plan in a scheduling application is translated into a set of start- and end-time variables and precedence constraints. The object model can be completely ignored when solving the scheduling problem. However, this complete separation of object model and constraint model is not possible for configuration problems, which poses new challenges for the modeling and the modeling language: Product catalogs: Configurators need to be deeply embedded in business processes and reuse existing product models in order to facilitate modeling and maintenance. Existing product catalogs in the form of database tables need to be mapped to constraint models. Since they strongly influences the structure of the constraint model, they cannot be ignored when discussing constraint models for configuration. Knowledge representation: Knowledge of the component structure is usually represented in the form of a taxonomy of component types. More specific types add attributes, domain restrictions, and subcomponents. Whereas object-oriented programming assumes that the type of an object is static, it is represented as a variable in constraint-based configuration. Constraint reasoning can specialize the component by reducing the domain of the type variable. The component then inherits the properties of the more specialized types during the solving process, which leads to the activation of new variables and constraints. The constraint engine has to support this inheritance process. Resource constraints: The number of parts of a configuration may not be bounded, but depends on global resource requirements. Hence, the set of components is not given in this case, but has to be determined as a result of the configuration task. In order to express constraints on those unknown parts, universally quantified constraints are necessary. Furthermore, variables representing the choice of an unknown part will have an open domain that is extended during constraint solving. Constraints on variables with open domains such as resource constraints need to deal with this situation. Preference models: A further challenge is obtained by the potentially huge set of solutions. Since these solutions differ much in their characteristics, user preferences need to be taken into account when solving the configuration problem.
24.1.3
Problem Solving Challenges for CP
The solving process faces additional challenges that depend on the type of the configuration problem. Configurators for manufacturing and engineering need to handle the following issues in addition to normal solving strategies for CP: Top-down refinement: a search strategy for finding a configuration cannot make decisions in an arbitrary order, but needs to implement top-down refinement that configures components before their subcomponents and that specializes the type variable before instantiating inherited attributes. Component generation: resource requirements may require the generation of an unbounded number of parts. Generation steps need to be incorporated into the solving strategy. A careful control of the generation is needed in order to avoid cyclic reproduction of the same state and to avoid the inclusion of parts that do not fulfill any function. Although interactive sales configurators are treating much simpler problems, they are facing challenges as well: User Scalability: web-based configurators need to solve many similar problems and this within short response times. It is therefore reasonable to share information between
844
24. Configuration
different threads (e.g. learning of strategies, conflicts, and solutions) or to preprocess the catalog by knowledge-compilation techniques. Explanations: interactive configurators let the user make the choices. As the user may easily encounter over-constrained problems, an explanation of failure in the form of conflicting requirements is needed. An explanation facility is a critical feature for an interactive configurator. Preference elicitation: interaction cycles can be shortened if the configurator remembers or acquires user preferences. The configurator can thus offer a preferred solution and automatically reactivate preferred choices when the user takes back options that are in conflict with those choices.
24.2 Configuration Knowledge This section introduces the knowledge that exists about components, namely component catalogs in sub-section 24.2.1, component structure in sub-section 24.2.2, and component constraints in sub-section 24.2.2. It introduces the different ingredients of a component such as functions (features), attributes, subcomponents and connections, and resources and provides the basic vocabulary for formulating constraint models.
24.2.1
Configuration Catalog
The literature distinguishes a large variety of configuration problems. In spite of this diversity, all those problems are based on the notion of a primitive component that does not contain subcomponents and that directly fulfills a required function. Each primitive component has a concrete type and a set of attributes describing the functional and technical characteristics of the component. Functional characteristics are either capabilities which are described by boolean attributes (such as printing) or capacities which are described by numerical attributes (such as storage capacity). A concrete type is a product type that can be ordered by the customer (in the case of a sales configurator) or that can be produced (in the case of a configurator for manufacturing). The technical characteristics are represented by further attributes that are either uniquely specified for the concrete type or that have multiple options. A primitive component is thus characterized by its type and the values of its attributes. Knowledge about the available primitive components is available in the form of product catalogs. The product catalogs are an integral part of enterprise resource planning (ERP) systems that support engineering and manufacturing. As it is important to embed configurators into those business processes, configurators need to reuse existing product models to facilitate modeling and maintenance. The product catalogs are available in the form of database tables. Each table describes a technical (component) type. There may be a table for hard disks, another one for video cameras, and another one for DVD players. A technical type defines the functional and technical attributes of a component, but does not specify the values for those characteristics. A technical component can be realized by multiple concrete (component) types. A concrete type specifies a concrete value for each attribute or gives the set of possible attribute values. For example, a concrete screen type may have a fixed size or a small set of possible sizes. The set of possible values can be expressed by an enumeration of values or by a range of two numerical bounds. The domain
U. Junker
845
Table 24.1: Catalog (video camera). Type cam1 cam2 cam3 cam4
Output analog AVI anal.+AVI. AVI
Input none none AVI AVI
price 200 300 400 500
of an attribute for a concrete type can thus be a singleton, an interval, or an enumeration of values. Whereas a single database column is sufficient for singleton domains, two columns are needed to represent interval domains. Attributes with enumerated domains may be represented by further tables. As a consequence, a product catalog in the form of a database does not directly reflect the product model. Annotations of the database are needed to interpret them in terms of a product model and to transform them into the following form: Definition 24.1 (Catalog knowledge). A configuration catalog is described by a set T of technical types, a set L of concrete types (the leaf types), and a set A of attributes that are all mutually disjoint. Each technical type t in T has a set attrs(t) ⊆ A of attributes and a (non-empty) set subtypes(t) ⊆ L of concrete types. The set of leaf types of two different technical types are mutually disjoint. Each technical type t has a table which defines a domain D(a, t ) for each attribute a ∈ attrs(t) and each product type t ∈ subtypes(t). Table 24.1 describes the catalog of video cameras. The first column describes the camera type. The other columns specify the values for the input and output formats and the price. This catalog is important when setting up a constraint model. Firstly, it provides the domains for the variables that are introduced for attributes. Secondly, it defines a constraint between the concrete type of a component and its attributes. We call this the catalog constraint. This constraint expresses a relationship between functional requirements and the technical characteristics of a primitive component, including its type. Given a user requirement on a functional property (e.g. a maximal price of 300), local consistency methods will remove all concrete types that are unable to provide this property (such as the camera types cam3 and cam4). As a consequence, the remaining types are able to meet this functional requirement. Thus, existing product models yield an important part of a constraint-based configuration model. Catalog constraints are particularly important since they are able to classify a component by reducing the domain of its type variable.
24.2.2
Partonomies and Taxonomies
Whereas sales configurators often deal only with primitive components, manufacturing and engineering needs to refine those components by suitable parts. The part-of-structure of components is therefore of central importance for configuration. A composite component has a concrete type, a set of attributes, and a set of subcomponents (or parts), which may be primitive or composite components. Following [16, 39], it makes sense to stipulate that components own their subcomponents. Hence, a subcomponent cannot be a part of two different components. Furthermore, the part-of-relation between components must neither contain cycles, nor infinite descending chains. A (sub)-
846
24. Configuration
camera
Home Movie Studio
... ....... ....... ... ... ....... ....... ...
1..1
computer
0..1
Camera
Computer
.... ...... ...... disks ...
1..n
Hard disk
Figure 24.2: A partonomy of functional and technical types.
component may also have a set of connections to other (sub)-components of the configuration. There are no restrictions concerning connections. Subcomponents as well as connected components can be grouped together into subsets of components, which are called ports in [44]. A port contains components that are functionally equivalent for the given problem. We distinguish partonomic ports that contain subcomponents and connectionports that contain connected components. Partonomic ports own their elements and are mutually disjoint. The structure of a composite component is defined by a structural product model. The partonomy describes the possible decompositions of components of a given type. Figure 24.2 shows the partonomy of a simple home movie studio. It consists of a camera and an optional computer which can have several hard disks. Such a partonomy can be complemented by a ‘topology’, which defines the connections between components and which consists of arbitrary relations between the types of a partonomy. Product models in ERP systems contain information about the partonomy. The bill-ofmaterial (BoM) describes how many subcomponents of which type are needed to assemble or to manufacture a component. A BoM is represented by a graph. The nodes are component types. The edges represent has-Part-relations and are labeled with a cardinality. An edge from type t1 to type t2 with label k means that a component of type t1 contains k subcomponents of type t2 . It can be assumed that a bill-of-material of configurable products is a directed acyclic graph. A BoM can easily be translated into a partonomy. Each node in the BoM corresponds to a technical type and each edge from type t1 to type t2 with label k in the BoM is translated into a 1 : k-relation from t1 to t2 . Concrete types specify or restrict the attribute values of a component. They may also specify the number of parts of a component (e.g. the number of wheels of a car). Technical types define the functional and technical attributes and the component structure. They regroup together multiple concrete types. However, it makes sense to further regroup technical types according to their functional characteristics. For example, the device for storing an edited movie can be a hard disk, a DVD writer, or a video recorder, or the camera itself. It therefore makes sense to regroup these technical types under a functional type called storage device. This functional type defines functional attributes such as a writing capability and the storage capacity. We thus obtain a taxonomy of types that consists of three layers: 1. A hierarchy of functional types. 2. A layer of technical types. 3. The leaf layer of concrete types. It is then possible to create an instance of a functional type, such as a storage device, and to configure it by specializing its type. This process will add new attributes to the component and refine its structure incrementally. A taxonomy thus describes alternative ways to map functional requirements to structure and to refine structural skeletons. Partonomies with taxonomies correspond to bill-of-materials with alternatives. Figure 24.3 shows the partonomy of the
U. Junker
Functional 0..n Unit ... ... ... .. ... ..... .. ... ..... ..... .....
Film Unit
...... ... ...
Manual
Edit Unit ..
.. .. ... ....
... ....... ....... ...
Home Movie Studio total price
Manual
edit capacity edit format
.............
Device ..... .... ....
Computer
Video Device.. ..
0..n .. .. ... .... Hard Disk storage capacity
..... .... ....
Computer− based
computer
0..n devices
... ....... ...... ... disks
... ....... ....... ...
1..1
Show
...........Unit ..... . .... ...
Computer−............. . . based .....
functions
847
DVD
.. .. ... ....
Camera
output format input format
Video
Recorder
Figure 24.3: A partonomy with taxonomy.
home movie studio which consists of functional units and devices. The functional units describe how the filming, editing, showing functions are realized. The edit and show unit can be manual or computer-based. Depending on these choices, different kind of devices need to be added. There is also a connection port indicated by a dashed line. A partonomy with a taxonomy can be represented in the form of a UML-diagram [16] or by a description logic. We define the structure of a component independent of a formal language: Definition 24.2 (Structural knowledge). A structural configuration model consists of a set Tˆ of functional types, a set T of technical types, a set Aˆ of attributes, a set Pˆ of partonomic ˆ of connection ports, all mutually disjoint: ports, and a set of Q 1. Each functional type t ∈ Tˆ has a (possibly empty) set subtypes(t) ⊆ Tˆ ∪ T of direct subtypes. The set of direct subtypes of two types are mutually disjoint meaning that each type has at most one direct supertype. 2. Each functional or technical type t in Tˆ ∪ T has a set attrs(t) ⊆ Aˆ of attributes ˆ of partonomic and connection ports. Each port p has a and a set ports(t) ⊆ Pˆ ∪ Q destination type type(t, p) ∈ Tˆ ∪ T , a minimal cardinality min(t, p), and a maximal cardinality max(t, p). 3. There is no sequence t1 , . . . , tn of types in Tˆ ∪ T such that t1 = tn and ti is a subtype of ti−1 or the destination type of a partonomic port of ti−1 . A structural configuration model can be extended by a configuration catalog if both coincide in their technical types as well as in the attributes attrs(t) of each technical type. A configuration can be obtained from a structural model by instantiating a component type. Table 24.2 shows the instance ourStudio of the Home Movie Studio which inherits the attributes and ports of this type. The attributes are assigned to values from the attribute domain and the ports are filled by part lists. For each part, a type is chosen and the part inherits the attributes and ports of this type, meaning that this process is repeated recursively. Hence, a structural configuration model generates a nested data structure when being instantiated. This data structure is central for the modeling and solving of configuration problems. In the remainder of this chapter, we need to refer to different elements of this data structure. Firstly, we will define a view on all the parts of the
848
24. Configuration Table 24.2: A configuration. ourStudio: a Home Movie Studio . total price: 2000 $ . functional units: . . unit(ourStudio,1): a Film Unit . . unit(ourStudio,2): a Computerized Video Edit Unit . . . edit capacity: 20 hours . . . edit format: AVI . . . computer: device(ourStudio,2) . devices: . . device(ourStudio,1): a Cam4 Camera . . . output format: AVI . . . input format: AVI . . device(ourStudio,2): a Computer . . . external hard disks . . . . disk(device(ourStudio,2),1): a Hard Disk . . . . . storage capacity: 120 GB . . . . disk(device(ourStudio,2),2): a Hard Disk . . . . . storage capacity: 160 GB
(an attribute) (a partonomic port) (a part) (a part)
(a connection port) (a partonomic port) (a catalog part)
(a catalog part) (a partonomic port) (a catalog part) (a catalog part)
component. This view includes also the indirect parts, i.e. the parts of the parts of the component and so on. In the example, the part view contains ourStudio, unit(ourStudio,1), unit(ourStudio,2), device(ourStudio,1), device(ourStudio,2), disk(device(ourStudio,2),1), disk(device(ourStudio,2),2). The part view contains all parts that are generated for a configuration. This information will be needed when we model connection ports as these ports are filled with the generated parts. Secondly, we define a view on all ports of a component. This includes the direct ports of a component, but also the ports of all components that are contained in a given port. As a port describes a set of parts that play the same role in a configuration, most configuration constraints are formulated with the help of ports. For example, if we want to sum the storage capacities of all the hard disks of the home movie studio, we need an indirect port that contains all the hard disks of the studio. Thirdly, we introduce a view on the properties of a direct or indirect port. An example is the storage capacities of our indirect hard disk port. In addition to the attributes, we include other properties, namely the types and the port cardinalities. All these properties can be subject to constraints. The property view is thus essential for the formulation of constraint models. All three views need to have counterparts in an expressive modeling language. We will define all the three views for an anonymous instance of a component type t. Not only does this instance inherit attributes and ports from the direct supertype super(t) i of t, but also from the indirect supertypes super∗ (t) := ∞ i=0 super (t). As the anonymous component can be specialized to any subtype of t, we take also attributes and parts of all the subtypes of t into account when defining the views. The direct and indirect subtypes are contained in subtypes∗ (t) := {t ∈ Tˆ ∪ T ∪ L | t ∈ super∗ (t )}. As components need to be ˆ specialized to leaf types, we also define the set of leaf types leaves(t) := subtypes∗ (t) ∩ L ˆ includes the types from Tˆ, T , and L that have no subtype. where L Now we formally define the part view. The set parts(x : t) of direct parts of a component x of type t is the smallest set which satisfies the following properties: 1. If p is a single-valued partonomic port of a type in super∗ (t) or subtypes∗ (t) then the port has a unique part p(x) in parts(x : t) which is an instance of the port’s destination type.
U. Junker
849
2. If p is a multi-valued partonomic port of a type in super∗ (t) or subtypes∗ (t) then the port has multiple parts p(x, 1), p(x, 2), p(x, 3), . . . in parts(x : t), which are all instances of the port’s destination type. If a set X of components is given, then their parts are determined by the element-wise application of the parts-function and we obtain the set of all direct and indirect parts of x by taking the reflexive and transitive closure: ∞ parts(X) := parts(x : t) and parts∗ (x : t) := partsi ({x : t}) (24.1) x:t∈X
i=0
The infinite set parts∗ (x : t) contains all potential parts for a component x. A configuration of the component x consists of a finite subset of this part universe. Next we define the port view. The set of ports ports(x : t) of a component x of type t is the set of all ports p(x) such that p is a (partonomic or connection) port of a type in super∗ (t). The set of ports of multiple components is obtained by the element-wise application of this operator. The reflexive and transitive closure defines the port view of x: ∞ ports(X) := ports(x : t) and ports∗ (x : t) := portsi ({x : t}) (24.2) x:t∈X
i=0
Each element p1 (p2 (. . . pk (x))) of ports∗ (x : t) has a minimal cardinality that is obtained by multiplying the minimal cardinalities of all the pi ’s and a maximal cardinality that is obtained by multiplying the maximal cardinalities of all the pi ’s. If the maximal cardinality is strictly greater than 1 then the port is called multi-valued. If the maximal cardinality is equal to 1 then it is called single-valued. If the minimal cardinality of a single-valued port is 0 then this port is called optional. Finally, we define the property view. The set props(x : t) of properties of a component of type t is the smallest set that has the following properties: 1. The leaf type type(x) of component x is in props(x : t). 2. If a is an attribute of a type in super∗ (t) then the attribute a(x) of x is in props(x : t). 3. If p is a multi-valued port of a type in super∗ (t) then the cardinality #p(x) of the port p(x) is in props(x : t) The set of properties of multiple components is obtained by the element-wise application of this operator: props(X) := props(x : t) (24.3) x:t∈X
Given this, we introduce the properties props(ports∗ (x : t)) of the component and of all its direct and indirect ports. A property of a single-valued port is called single-valued, that of a multi-valued port is called multi-valued, and that of an optional port is called optional. The constraint model needs to take into account the knowledge of the component structure. If an instance of a functional type is configured, then its type variable has all leaf types of the functional type as possible values. When constraint propagation reduces the domain of this variable, it automatically classifies the component, meaning that the component now belongs to a more specialized type. It then needs to inherit the properties of the specialized type. These properties can require further choices, meaning that new variables and their constraints need to be included in the constraint model. Constraint models that model this inheritance reasoning are therefore dynamic or conditional (see section 24.3.4).
850
24. Configuration Table 24.3: Compatibility of storage device and video format. Storage device hard-disk hard-disk DVD VCR Digital Camera Analog camera
24.2.3
Video Format AVI MPEG2 MPEG2 analog AVI analog
Configuration Constraints
If a catalog specifies unique values for all attributes, then functional requirements can simply be fulfilled by choosing a concrete type for each component. However, additional choices are necessary in the general case in order to configure a component. Firstly, a concrete component type may allow different possible values for technical attributes. Secondly, a component type may not have a fixed function, but permit a choice of alternative functions. In both cases, the attributes of the components may have multiple possible values even if the component type has been chosen. Not all the combinations of those values are legal. Configuration constraints describe which combinations correspond to legal product configurations. There are different kinds of configuration constraints, namely compatibility constraints, requirement constraints and resource constraints. A compatibility constraint specifies which value combinations are legal. It corresponds to a standard constraint in CSPs and has a relation R and a scope. The relation can be specified by a compatibility table which contains the valid value combinations or by an incompatibility table which contains the invalid combinations. These tables can usually be imported from the existing product model of an ERP system. However, the relation can also be specified by a predicate such as equality, inequality, greater-than. The relation is used to restrict the possible values of direct and indirect properties of a component x of a type t. Hence, the scope is an n-ary tuple a1 (x), . . . , an (x) of properties from props(ports∗ (x : t)). If these properties are all single-valued, then the constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∃(v1 , . . . , vn ) ∈ R : (a1 (x) = v1 ∧ . . . ∧ an (x) = vn )
(24.4)
The configuration satisfies ai (x) = vi iff it assigns the value vi to the property ai of x. Compatibility constraints may, in particular, be used to restrict combinations of the types of subcomponents. For example, figure 24.3 shows a compatibility constraint between the storage device type of the edit unit and the video file format of the edited movie. A requirement constraint is also specified by a table and a scope of component properties. However, it expresses a requirement relation between two component properties. A tuple (v1 , v2 ) in the requirement table means that the value v1 of the first property requires the value v2 for the second property. A requirement constraint for type t has a requirement table R and a scope a1 (x), a2 (x) consisting of single-valued properties from props(ports∗ (x : t)). The constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∀(v1 , v2 ) ∈ R : (a1 (x) = v1 ⇒ a2 (x) = v2 )
(24.5)
U. Junker
851
Table 24.4: Requirements for devices. Functional unit Film Unit Manual Edit Unit Computer-based Edit Unit Manual Show Unit Manual Show Unit Computer-based Show Unit
Required Device Camera Video Recorder Computer TV DVD Player Computer
Requirement constraints can be used to restrict combinations of the types of subcomponents. Figure 24.4 shows a requirement constraint between types of the functional units of the home movie studio and the types of its devices. For example, if the functional units include a film unit and a manual show unit, then the devices must include a camera, a TV, and a DVD player. Compatibility constraints can also be applied to multi-valued properties. For example, a computer component may contain a set of peripheries. This set will be subject to multiple compatibility and requirement constraints. However, these constraints are not applied to the components themselves, but to their types. For example, a scanner may require a printer. Two additional difficulties are arising then. Firstly, it is necessary to specify whether the constraint applies to all or to one value as the set of periphery types can contain multiple elements. Secondly, the table entry itself can represent sets of types, namely all the leaf types that specialize the functional or technical type originally listed in the table. The equality tests ai (x) = vi are therefore replaced by intersection tests of the form ai (x) ∩ Vi = ∅. This test is satisfied by a configuration of x if the configuration assigns at least one element of the set Vi to the property ai of the component x. Hence, a compatibility constraint for type t has a compatibility table R and a scope a1 (x), . . . , an (x) over props(ports∗ (x : t)). The constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∃(V1 , . . . Vn ) ∈ R : (a1 (x) ∩ V1 = ∅ ∧ . . . ∧ an (x) ∩ Vn = ∅)
(24.6)
A requirement constraint for type t has a requirement table R and a scope a1 (x), a2 (x) over props(ports∗ (x : t)). The constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∀(V1 , V2 ) ∈ R : (a1 (x) ∩ V1 = ∅) ⇒ (a2 (x) ∩ V2 = ∅)
(24.7)
Functional properties such as capacities can be seen as a resource that is provided by a system. An example is the storage capacity of a PC that is obtained as the sum of storage capacity of all its disks. The functional requirements usually state that a minimal amount of such a resource should be provided. To meet those requirements, a sufficient number of parts need to be created and configured. Not only can resources be provided by a system, but they can also consumed by it. An example is the total power consumption of a PC, which is the sum of the power consumption of the PC and of its parts. The functional requirements usually state that the consumption of such a resource should not exceed a maximal amount. It is also possible that intermediate components consume resources that
852
24. Configuration
need to be provided by other components. Following [31], resources thus express a balancing task between consumers and producers. Resource constraints [59] ensure that the amount of a produced resource is greater than or equal to the amount of a consumed resource. A resource constraint is applied to all components of a given type t. The consumers and the producers are both represented by subsets of ports∗ (x : t). The produced resource is expressed by a numerical attribute that must be defined for all producers. The consumed resource is expressed by a numerical attribute that must be defined for all consumers. Since both attributes can be different, the root component for the resource constraint can play the role of a producer and consumer. Hence, a resource constraint for a component x of type t is specified by a tuple (P roducers, Consumers, produced, consumed). This constraint is satisfied by a configuration if this configuration satisfies: p(x)∈P roducers
o∈p(x)
produced(o) ≥
consumed(o)
(24.8)
p(x)∈Consumers
o∈p(x)
This model covers also the case where an initial requirement for a minimal amount of a resource (such as storage capacity) needs to be provided by a component. In this case, the producers are the parts of the component (e.g. the storage devices) and the consumer is the component itself, which has a specific consumed-attribute for formulating the requirement (such as required-storage-capacity). Requirements that limit the amount of a consumed resource (e.g. the price) can be formulated as well. In this case, the consumers are the parts of the component and the producer is the component as well, which has a specific produced-attribute corresponding to the maximal amount. It is important to understand that resource constraints express a constraint between the total amount of the resource (i.e. the result of the sum), the bounds of the produced or consumed attributes defined in the catalog, and the number of components. In order to meet minimal cardinalities of ports, new components may be generated during the configuration process. This generation is limited to partonomic ports. Resource constraints can involve other aggregation operators than the sum. Alternatives are min, max, average. Resource constraints can also operate on sets and use a setunion as aggregation operator and the super-set-operator as comparison operator. This is needed to establish a domain for connection-ports. The connection-port (e.g. the storage device of an edit-unit) is a consumed resource that is produced by the actual parts (such as the disks of the computer, the DVD writer of the computer, or the camera). The constraint knowledge for a component x of type t can be summarized as follows: Definition 24.3 (Constraint knowledge). Each type t ∈ Tˆ ∪ T has a set Compat(x : t) of compatibility constraints, a set Requires(x : t) of requirement constraints, and a set Resources(x : t) of resource constraints. These sets are possibly empty. Component types have thus been enriched with three types of constraints, namely compatibility, requirement, and resource constraints. They are formulated on expressions that are defined by the structural model. The compatibility and requirement constraints additionally refer to database-tables that can be imported from existing ERP-systems.
U. Junker
853
24.3 Constraint Models for Configuration A configuration problem is defined by functional requirements and by a configuration model that describes the possible configurations according to the given configuration knowledge. The configuration models in the literature differ quite substantially in the way choices and constraints are represented, although they use the same product models at their origins. It is indeed possible to build different constraint models for the given configuration knowledge. It is even possible to use different constraint models for different component types, meaning that the configuration model is a hybrid one. We first define configuration problems in a general way. In particular, we explain when a configuration model satisfies the given functional requirements. Without loss of generality, it can be assumed that all components that need to be configured are direct or indirect parts of a single root component, which represents the system to be configured. This root component is an instance of a suitable component type, which regroups all the principal components of the system and which contains suitable attributes to describe the functional properties of the system. If such a type does not exist in the given configuration knowledge, then it is straightforward to add such a type description. Given the type t of the system to be configured, we define a functional space for t and a configuration space. The functional space describes the set of complete combinations of functions that can be achieved by an instance of t and the configuration space describes the set of complete configurations for an instance of type t. Such a configuration needs to describe the leaf type t∗ of the instance, the values of each attribute of t∗ (including those inherited from supertypes), the number of elements in each partonomic port of t∗ (including those inherited from supertypes), the configuration of each element of the partonomic port, and the values of each connection port of t∗ (including those inherited from supertypes). Hence, a configuration, in its fully expanded form, is a tree of property-value-pairs. Whereas the function space is finite and obtained as Cartesian product of the domains of the functional attributes of the root component, the configuration space is infinite, but contains finite elements. The function and the configuration spaces usually are not described explicitly, but implicitly by means of a suitable constraint language. Examples for constraint languages are OPL, the CLP(X)-family, or the API’s of constraint libraries. All these languages can be understood as fragments of first-order logic (cf. e.g. [25]) over a fixed structure. They provide a set of predicate symbols, which have a fixed interpretation and which are used to represent the relations of constraints. They also provide a set of function symbols, which have a fixed interpretation and which are used to formulate constrained expressions. Hence, a constraint language can be specified by a first-order language and a structure. For the purpose of configuration, the language is enriched by function symbols representing the ports and properties of components. The interpretation of these additional function symbols can be freely chosen when determining a configuration. A configuration problem for an instance x of type t is then specified by a set of functional requirements F (x : t) and a configuration model K(x : t). The functional requirements are expressed as constraints on the direct functional properties of the root component. The configuration model1 is expressed by constraints on arbitrary properties and 1 The term ‘configuration model’ should not be confused with a logical model of the configuration constraints. The logical model indeed corresponds to a configuration that satisfies those constraints.
854
24. Configuration
ports of the root component, including the functional and technical characteristics. The constraints can contain universal quantifiers, logical connectives, numerical operations, equalities, and comparisons. Compared to Solvers for classical CSPs, a configurator needs to handle these kinds of constraints as well as optional variables, partonomic ports, and variables and constraints with open domains. A configuration problem has a solution iff the union of the functional requirements and the configuration model is satisfiable, i.e. F (x : t) ∪ K(x : t) |= ⊥ [23]. As noted in [28], it is important that the resulting configurations are functionally complete. This means that the configuration S contains sufficient information to decide whether it satisfies an arbitrary requirement or whether it does not satisfy it. S is functionally complete iff either S |= F (x : t) or S |= F (x : t) holds for all requirements F (x : t). Functional completeness is easy to achieve in a constraint-based approach. It is sufficient to include the functional properties in the configuration. Or more formally: functional completeness is straightforward if the function space is obtained as a projection of the configuration space on the functional properties. As the configuration model is expressed in first-order logic, it is not evident whether a configuration problem is decidable. However, configuration problems satisfy the finite model property meaning that the (part) universe of a configuration is finite. The solution can thus be found by an enumeration of the universes. Secondly, the particular partonomic structure and constraint structure used in this chapter allows a complete calculus for proving non-satisfiability of an infeasible configuration problem. The proof can thus be found by enumerating all candidate proofs. The configuration problems considered in this chapter are therefore decidable. In its most general form, a configuration model must be able to describe configurations in its fully extended form where all parts are clearly distinguished and exhaustively described. However, it often is not necessary to distinguish all parts. For example, it may be reasonable to assume that the wheels of a car have the same characteristics. It is then sufficient to represent their number and their product type, which uniquely determines their attribute values. In even simpler problems such as option selection, it is even sufficient to characterize the set of options by a set of types. Hence, the representation of configurations can be simplified and this simplification leads to simpler problems. Simplified configuration problems are also obtained if the given configuration knowledge has a particular form. In the next sections, we introduce several kinds of configuration problems. We distinguish static problems describing a configuration by a fixed set of properties and dynamic problems that involve optional properties or even an unbounded number of properties. Static problems include option selection, shopping lists, or the configuration of systems with a fixed and deterministic structure (car configuration). Dynamic problems include systems with optional parts (computer configuration) and systems with an unbounded number of parts (such as rack configuration or bin packing).
24.3.1
Boolean Models for Option Selection
A very simple configuration problem is obtained if the configured system consists of a set of parts which are entirely characterized by their concrete types. An example is the selection of optional parts for the home movie studio such as a scanner, a printer, an external hard disk. Each option is described by an option type, which has no particular attributes, and each option type can be chosen once only. The options may be organized in a taxonomy
U. Junker
855
and are subject to requirement and compatibility constraints. The functional properties of the system are simply represented by boolean attributes that are linked with the option types via requirement constraints. Definition 24.4 (Option selection problem). The structural model of an option selection problem consists of a type S corresponding to the configured system, a functional type F regrouping all the functions and a functional type O regrouping all the options. The type S has a partonomic port that contains functions from F and a partonomic port that contains the options O. The type F is the root of a function taxonomy and the type O is the root of an option taxonomy, which has concrete types as leaf types. None of the types has attributes. There are requirement constraints between the types of the functions in the function-port and the types of the options in the options-port. There are requirement and compatibility constraints between the types of options in the options-port. The configurations of an option selection problem can be described by a boolean constraint model. This model has the following boolean variables: • A boolean variable fi for each type in the function taxonomy subtypes∗ (F ). This variable has the value 1 iff the configured system has a function of this type. • A boolean variable tj for each type in the option taxonomy subtypes∗ (O). This variable has the value 1 iff the configured system has an option of this type. An entry (f, t) in a requirement constraint between the types of the functions in the functionport and the types of the options in the option ports is represented by an implication: f ⇒t
(24.9)
The direct subtypes t1 , . . . , tn of t in the options or function-taxonomy are modeled by a disjunction: t ≡ t 1 ∨ . . . ∨ tn
(24.10)
A compatibility constraint between the types of the options in the option port can be represented by a set of negative clauses supposing that the constraint has a negative table N which contains the forbidden tuples: ¬t1 ∨ ¬t2
for all (t1 , t2 ) ∈ N
(24.11)
User requirements can be represented by constraints involving the boolean variables f for the function. A boolean problem can be solved by a SAT-solver. Option selection problems are interesting because they can appear as subproblems of more complex problems. This means that the type S is not the root type of a partonomy, but describes the parts of another type. In this case, the boolean variables need to be skolemized since they depend on a component y. The result of the skolemization are terms such as fi (y) and tj (y). An alternative is to use set variables [48] to describe the set of types of all elements in a port. For example, a set variable t(y) could describe all the option types that have been chosen.
856
24. Configuration
24.3.2
Cardinality Models for Shopping Lists
A more complex type of configuration problem is obtained if the functional requirements specify how often a certain functionality should be provided. For example, the home movie studio may require a certain storage capacity for videos and multiple hard disks are needed to provide this capacity. We thus obtain a shopping list and it is necessary to choose the number of instances of a product type. However, the instances need not be distinguished for computing the amount of the consumed and the produced resources as long as these resources have unique values for leaf types. Definition 24.5 (Shopping list problem). The structural model of a shopping list problem consists of a type S corresponding to the configured system (the shopping basket), a functional type F regrouping all the functions, and a functional type I regrouping all the items. The type S has a partonomic port that contains functions from F and a partonomic port that contains the items from I. The type F is the root of a function taxonomy and the type I is the root of an item taxonomy, which has concrete types as leaf types. The types can have attributes, but the values of an attribute a need to be uniquely specified by the leaf types t in the form of a value value(t, a). There are binary requirement constraints between a type of a function in the functions-port and the type of an item in the items-port. There are binary requirement and compatibility constraints between the types of the items in the items-port. Furthermore, there are resource constraints between the function-port and the items-port. The consumed resource is an attribute of F and the produced resource is an attribute of I. The configurations of a shopping-list problem can be described by a cardinality model. This model has the following integer variables: • A positive integer variable #fi for each type in the function taxonomy subtypes∗ (F ). This variable indicates how many times the configured system provides a function of this type. • A positive integer variable #tj for each type in the item taxonomy subtypes∗ (I). This variable indicates the number of items of this type in the configured system. An entry (f, t) in a requirement constraint between the types in the function-port and the types in the items-ports is represented by an implication: (#f ≥ 1) ⇒ (#t ≥ 1)
(24.12)
The direct subtypes t1 , . . . , tn of t in the item taxonomy or the function taxonomy are modeled by a sum. This is possible since two different subtypes have no leaf type in common: #t = #t1 + . . . + #tn
(24.13)
A compatibility constraint between the types of the items in the item-port can be encoded by negative clauses if it is specified by an incompatibility table N : #t1 = 0 ∨ #t2 = 0 for all (t1 , t2 ) ∈ N
(24.14)
U. Junker
857
A resource constraint between a resource c that is consumed by the functions in the function port and a resource p that is produced by the items in the item-port can be modeled by a linear constraint: (24.15) t∈leaves(F ) value(t, c) · #t ≤ t∈leaves(I) value(t, p) · #t User requirements can be represented by constraints involving the integer variables #f for functions. A shopping-list problem can be solved by an Integer Programming approach similar to that in [62]. Shopping list problems can also appear as subproblems of more complex problems. Similar to option selection problems, a single multi-valued variable can be introduced to describe the number of types in a function port or the number of types in an item port. In the case of shopping-lists, the multi-valued variable is a multi-set or bag variable.
24.3.3
CSP-Models for Customizing Flat Components
The configuration model needs to distinguish individual components if the attribute values of the components are not fully determined by the concrete product type. In this case, additional choices are needed to characterize the components and it is necessary to introduce variables for the attributes. For example, the video edit facility requires the customization of several technical components such as the computer, the editing software, the printer, and the scanner. Each of those components has several attributes which are naturally encoded by variables. Those variables are subject to constraints and we obtain a standard constraint satisfaction problem for this flat configuration problem. Definition 24.6 (Flat Customization Problem). The structural model of a flat customization problem consists of a type S corresponding to the configured system, technical types T1 , . . . , Tn representing the principal components. The types need not be all different. The type S has a partonomic port pi that contains exactly one instance of type Ti . The type Ti is a technical type that has concrete types as subtypes. The types S and the types Ti have multiple attributes containing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. There are arbitrary requirement and compatibility constraints between the direct and indirect attributes of the configured system. There are resource constraints between direct attributes of the configured systems and the attributes of the components. The configurations of a flat customization problem can be described by a constraint satisfaction problem. The model has the root component o0 of type S, the components oi which are equal to the ports pi (o0 ), and the following variables: • A variable aj (o0 ) for each attribute aj of the configured system o0 . • A variable aj (oi ) for each attribute aj of the component oi . • A type variable type(oi ) for the type of the component oi . The domain of this variable are the subtypes of Ti . The catalog is translated into an element constraint for each attribute aj and each component oi where i = 1, . . . , n. If subtype t of type Ti restricts the domain of attribute aj to D(t, aj ) then the element constraint is as follows: ∀t ∈ leaves(Ti ) : type(oi ) = t ⇒ aj (oi ) ∈ D(t, aj )
(24.16)
858
24. Configuration
Compatibility constraints can be applied to arbitrary direct and indirect attributes of the configured system, which are represented as variables aj1 (oi1 ), aj2 (oi2 ) where i1 , i2 are in {0, . . . , n}. Hence, the compatibility constraint is expressed as a standard constraint: ∃(v1 , v2 ) ∈ R : (aj1 (oi1 ) = v1 ∧ aj2 (oi2 ) = v2 )
(24.17)
Requirement constraints are expressed similarly in their natural form: ∀(v1 , v2 ) ∈ R : (aj1 (oi1 ) = v1 ⇒ aj2 (oi2 ) = v2 )
(24.18)
Finally, resource constraints can sum up a produced resource aj of multiple components in P ⊆ ports∗ (o0 : S) and a consumed resource aj of multiple components in C ⊆ ports∗ (o0 : S). As the set ports∗ (o0 : S) is equal to the set of components o0 , o1 , . . . , on , the resource constraint is expressed in terms of a numerical constraint: aj (oi ) ≥ aj (oi ) (24.19) oi ∈P
oi ∈C
The functional requirements for flat component properties can be expressed in terms of any functional attribute, whether it is a direct attribute of the configured system or an attribute of one of its components. A flat customization problem can be solved by a constraint solver. If the constraint graph is not dense, appropriate decomposition [13, 26] and clustering techniques can be applied [14] to solve it efficiently.
24.3.4
Conditional CSPs for Taxonomic Reasoning
The same functionality can often be realized by components differing greatly in their technical characteristics. As described in section 24.2.2, technical types fulfilling the same functionality are therefore organized in a taxonomy. Subtypes add further attributes, which means that the set of attributes of a component depend on its precise type. We thus obtain taxonomic customization problems. Formulating this problem as a standard CSP would require including a variable for each possible attribute that can be inherited and ensuring that its value is not meaningful in case it is not inherited. As an alternative, Mittal and Falkenhainer [43] introduced dynamic CSPs with optional variables that are activated under certain conditions. As the term dynamic CSP was later used for CSPs able to support constraint addition and retraction, it was proposed to rename the approach into Conditional CSPs [52]. As observed by Bowen and Bahler [7], it is also possible to directly use first-order logic to model taxonomic customization problems. A further proposal is that of composite CSPs [50], where the variable domains may contain sub-CSPs which are activated when this value is chosen. We model taxonomic customization as a Conditional CSP model, since dedicated algorithms have been elaborated for this approach [52, 24]. Definition 24.7 (Taxonomic Customization Problem). The structural model of a taxonomic customization problem consists of a type S corresponding to the configured system, functional types T1 , . . . , Tn representing the principal components. The types are not necessarily different to each other. The type S has a partonomic port that contains exactly one instance of Ti . The type Ti is the root of a taxonomy, which has concrete types as leaf types. The types S, the types Ti , and the subtypes of the Ti ’s have multiple attributes
U. Junker
859
containing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. A constraint on a type t of the taxonomies can involve any property of type t. There are different possibilities to represent the type variables of the components. It is not only necessary to model that components are instances of concrete product types, but also that they are instances of functional or technical types, such as the technical DVD-type in the following example: if the video edit device is a DVD, then it requires an MPEG2 format. A possibility is to represent type variables as hierarchical variables [38]. An alternative is to use the same representation as for flat problems and to express an instanceof-constraint by a constraint that is satisfied if the value of the type variable is an element of the set of leaves of the type t. This approach has an efficient implementation [40] and is conceptually simpler. For example, the element-constraint representing the catalogs need not be extended to range over functional and technical types. The element-constraint from section 24.3.3 is therefore valid for taxonomic customization problems. Attributes are represented by variables, which can be optional. If type t has an attribute aj and oi is an instance of a supertype of t then the variable aj (oi ) is activated if oi is an instance of t. The activation is denoted by active : aj (oi ), which is a (non-optional!) boolean variable attached to the attribute: type(oi ) ∈ leaves(t) ⇔ active : aj (oi )
(24.20)
The solution of a Conditional CSP just contains the variables for which the active-condition is true. It is convenient to represent such a solution by a set of attribute-value pairs. Compatibility constraints for type t are only activated if the component is an instance of t: (active : aj1 (oi ) ⇒ aj1 (oi ) = v1 ) ∃(v1 , . . . , vk ) ∈ R : ∧ . . . ∧(active : ajk (oi ) ⇒ ajk (oi ) = vk )
(24.21)
Requirement constraints can, however, activate variables: ∀(v1 , v2 ) ∈ R :
(active : aj1 (oi ) ∧ aj1 (oi ) = v1 ) ⇒ (active : aj2 (oi ) ∧ aj2 (oi ) = v2 )
(24.22)
The activation of attributes has also an impact on resource constraints. A resource of type t is provided (or consumed) by a component only if this component is an instance of t. Hence, a resource constraint can only take active resources into account. It may activate produced resources and deactivate consumed resources: aj (o) ≥ aj (o) (24.23) o∈P
active:aj (o)
o∈C
active:aj (o)
Although Conditional CSPs handle the inheritance of attributes, they require that all optional variables and their constraints are created explicitly. The use of universally quantified constraints avoids the creation of optional variables and their constraints if they are not needed. If a component o is an instance of type t, then instances of the constraints of t will be created. For this purpose, the quantified variable of the constraint will be substituted by the component o. It is important to note that a quantified constraint of type
860
24. Configuration
t will only be applied to instances of type t. To achieve this, a set variable instances(t) is introduced to represent the instances of type t. It is linked to the type-variables via an inverse-constraint: ∀i ∈ {0, . . . , n}∀t ∈ subtypes∗ (Ti ) : type(oi ) ∈ leaves(t) ⇔ oi ∈ instances(t) (24.24) The type variable is needed for the catalog constraints, whereas the instance-set variable is used to replace the active-variable. By definition, x ∈ instances(t) is equivalent to active : aj (x) and we can reformulate a compatibility constraint as a universally quantified constraint of type t: ∀x ∈ instances(t) : C(ai1 (x), . . . , aik (x))
(24.25)
If o is an element of instances(t), the forall-constraint adds the variables ai1 (o), . . . , aik (o) and the constraint C(ai1 (o), . . . , aik (o)) to the current CSP. Resource constraints can be adapted by sums that range only over the instances of the types for which the resource is defined.
24.3.5
Conditional CSPs for Simple Partonomic Reasoning
Configurable systems such as computers usually consist of a partonomic hierarchy that has more than two levels. The first level corresponds to the system to be configured and the second level contains the principal components of this system. These principal components may themselves have subcomponents some of which may be optional and some of which depend on the type of the principal component. Furthermore, the subcomponents may be connected to each other. An example is a PC, which has a central unit, which has a processor, which has an optional co-processor. Another example is car configuration with options [43]. We thus obtain a partonomic customization problem which requires the recursive configuration of possibly optional subcomponents and the choice of connections. The problem can again be modeled by a Conditional CSP or by first-order logic. Definition 24.8 (Simple Partonomic Customization Problem). The structural model of a simple partonomic customization problem consists of a type S corresponding to the configured system. S is the root of a partonomy with a taxonomy and a topology such that all partonomic and connection ports contain at most one component. The types in the partonomy can have multiple attributes describing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. A constraint on a type t of the partonomy can involve any property of type t. Special attention needs to be paid naming the properties of subcomponents. Independent of the formalisms, the terms as introduced in section 24.2.2 appear to be the appropriate way. We use the single-valued ports in ports∗ (x : t) and the single-valued properties in props(ports∗ (x : t)) for this purpose. Not only can a component have optional attributes, it can also have optional subcomponents and optional connections, which become active if the component is an instance of the corresponding type. However, there may also be subcomponents and connections that are optional in the sense that the corresponding relation has a minimal cardinality of 0 and a maximal cardinality of 1. If the subcomponent or connected component does not exist, then they are considered inactive as well. If a component is not active then none
U. Junker
861
of its properties and of its ports are active. Therefore, only a subset of ports∗ (x : t) and props(ports∗ (x : t)) are active in a solution. A solution consists of a set of valueassignments to the active properties and to the active connections. The activation of ports can be well addressed by a Conditional CSP or a first-order approach if the properties and ports are modeled as follows: 1. The partonomic ports are treated as variables that are assigned to themselves. 2. The properties of partonomic ports are modeled by variables as before. 3. A connection-port p of a component o of type t is treated as a variable p(o). The domain of p(o) contains the possible instances of the destination type t := type(t, p) from the set of all parts parts∗ (o0 : S) of the root type S. A constraint ensures that the value of p(o) has the type t : ∀o ∈ parts∗ (o0 : S) : p(o) = o ⇒ type(o ) = t
(24.26)
4. The properties and ports ξ(p(o)) of connection-ports are equal to the properties and ports of the component that is assigned to this connection-port. An elementconstraint is needed to express this correspondence: ∀o ∈ parts∗ (o0 : S) : p(o) = o ⇒ ξ(p(o)) = ξ(o )
(24.27)
Hence, single-valued partonomic ports can be handled in a straightforward way. Connection ports, however, are variables that require a special domain management.
24.3.6
Generative CSPs for Complex Partonomic Reasoning
The general case of a configuration problem is obtained when partonomic ports and connection ports can contain an arbitrary number of components. Typical examples occur in equipment configuration where given resource requirements (e.g. on storage capacity) need to be covered by an unknown number of components. Conditional CSPs are no longer appropriate to treat these unbounded configuration problems, since they require the precreation of an infinite number of possible parts. Generative CSPs [60, 59, 17] have been elaborated to handle these complex customization problems. The essence of the generative approach can be described in terms of a first-order formulation. Definition 24.9 (Complex Partonomic Customization Problem). The structural model of a complex partonomic customization problem consists of a type S corresponding to the configured system. S is the root of a partonomy with a taxonomy and a topology. The partonomic and connection ports can contain an arbitrary number of components. The types in the partonomy can have multiple attributes describing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. A constraint on a type t of the partonomy can involve any property of type t. The ports of complex partonomic customization are arbitrary elements of ports∗ (x : t) and the properties are arbitrary elements of props(ports∗ (x : t)). Constraints can thus be
862
24. Configuration
formulated on the properties of multi-valued ports. In contrast to an optional port, a multivalued port is active even if it has no element. Hence, there is not need to dynamically activate multi-valued ports. However, it is necessary to dynamically generate new components to meet cardinality constraints on ports. It is sufficient to generate parts for direct ports p(x) ∈ ports(x : t) of a component x. This is achieved by a generative constraint that creates the parts when the lower bound of the cardinality is increased and that adds them to the instance-set of t. This instance-set needs to be represented by a set variable [48] with an open domain [40]: ∀i ∈ {1, 2, 3, . . .} : #p(o) ≥ i ⇒ p(o, i) ∈ instances(t)
(24.28)
If a configuration assigns the value k to the cardinality of a direct partonomic port p of a component x, then the configuration will contain the parts p(x, 1), . . . , p(x, k), but not any other part p(x, k ) with k > k. Since the partonomy is acyclic, each configuration can only contain a finite number of parts. The generative constraint thus generates components on a by-need-basis. It also imposes an important constraint on the port cardinality. If the configuration of the k-th part fails, then it cannot belong to the instance-set meaning that the cardinality of the port is strictly smaller than k. Hence, infinite chains for generating parts are broken as soon as a part cannot be configured. However, infinite ascending chains could be obtained by a search procedure that successively increases the lower bound for the cardinality #p(o) in a search branch. It is nevertheless possible to impose an upper bound on the cardinality based on the following argument. Since components are generated to meet requirement and resource constraints, we determine how many components each such constraint may generate for the port p(o) and use the sum of those upper bounds as an upper bound of the cardinality. We can compute the upper bound for a resource constraint as soon as the total resource consumption has been established. We suppose that the produced resource of each component in the port is greater than a strictly positive lower bound. We can then calculate the upper bound of the number of components by dividing the total amount of the resource by this lower bound. It is important to note that this upper bound on the cardinality imposes an additional constraint on the configuration space. It eliminates configurations with a large number of parts that don’t have any function. Ports of multi-valued partonomic ports can be modeled by recursive constraints. Let ξ be a single-valued port of the destination type of the partonomic port p. The port ξ(p(x)) is then multi-valued. We introduce auxiliary set variables ξ(p(o), i) for the subset that is contributed by the parts p(o, i + 1), p(o, i + 2), . . . , p(o, k), where k is the cardinality: ξ(p(o)) := ξ(p(o), 0) {ξ(p(o, i + 1))} ∪ ξ(p(o), i + 1) if #p(o) ≥ i + 1 ξ(p(o), i) = ∅ otherwise
(24.29)
Multi-valued ports ξ are handled by a similar recursive constraint that directly uses the port ξ(p(o, i + 1)) of the i + 1st component in the union-operation instead of {ξ(p(o, i + 1))}. Properties of partonomic ports are calculated in a similar way except that they are formulated on multi-set (or bag) variables instead of the set variables. If r is a resource of the destination type of a partonomic port, then the resource of the port can be modeled in a recursive way as well. Auxiliary variables r(p(o), i) denote the
U. Junker
863
contribution of the parts p(o, i + 1), p(o, i + 2), . . . , p(o, k), where k is the cardinality: r(p(o)) := r(p(o), 0) r(p(o, i + 1)) + r(p(o), i + 1) if #p(o) ≥ i + 1 r(p(o), i) = ∅ otherwise
(24.30)
A connection port of type t is modeled by an open set variable that is a subset of instances(t). As the elements of connection ports are not ordered, specific union- and sum-over-set-constraints have been introduced in the generative CSP-approaches [40]. The sum-over-set constraint maintains a local consistency among the lower and upper bounds on the port cardinality, the lower and upper bounds on the sum, the set of required elements in the set variable, and the lower and upper bounds of the resources provided by the required elements.
24.3.7
Complex Cases
Complex configuration models can be obtained by combinations of the previously defined models. In particular, components at the leaf level of the partonomy often do not need to be distinguished, thus allowing the use of a boolean or cardinality model. Complex problems are also obtained by more sophisticated representations of the functional properties. Functions can be composed of sub-functions meaning that they are represented by a function partonomy. Functions are then assigned to components and subfunctions need to be assigned to their subcomponents. The sub-functions fulfilled by the subcomponents of a component need to be equal to the sub-functions of the function that is fulfilled by the component. This homomorphism can be expressed by an equality of two union-over-set-constraints. The refinement of function occurs, for example, in the configuration of instrumentation-and-control systems [40] and electrical wiring systems [1]. Complex connection reasoning leads to similar problems if connections between principal components are refined by connections between subcomponents.
24.4 Problem Solving for Configuration Whereas Constraint Programming is used to find a solution or an optimal solution of a CSP, configuration brings in new problem-solving tasks, such as the maintenance of global consistency in interactive configuration, the computation of an explanation if a given set of requirements cannot be satisfied, or the computation of a relaxation of those requirements. The automatic computation of configurations also has particularities. Solution search should produce functionally well-justified configurations instead of an arbitrary configuration. If optimal configurations are required, then the user preferences are rarely specified in terms of a single criterion, but typically involve multiple criteria.
24.4.1
Interactive Configuration
Sales configurators are usually interactive as the functional requirements evolve during the decision-making process. An interactive configurator shows the functional characteristics of the configured system in the form of a web page or a GUI. Each functional attribute is characterized by its possible values. The user can express bounds on these attributes,
864
24. Configuration
eliminate possible values, or choose a value. The configurator typically reacts to those user inputs by propagating their logical effects. If a value is no longer possible for an attribute, then the configurator can eliminate it. Interactive configuration has, for example, been studied in [2] and in the CAWICOMS-project [3]. Definition 24.10 (Interactive configuration task). Given a configuration model K(x : t), user requirement F (x : t), and a set of variables Y representing the functional characteristics, the task consists in finding the set D(y) of legal values for each variable y ∈ Y . A value v is legal for y iff there exists a configuration that satisfies K(x : t) ∪ F (x : t) and that assigns v to y. This task is solved by maintaining global consistency [19] for the functional requirements. A domain D(y) of a variable is globally consistent iff each value v in D(y) is legal for y. An initial domain Dinit (y) taken from the configuration model K(x : t) can be reduced to a maximally global consistent domain D∗ (y) by inspecting each value v of Dinit (y) and by checking whether F (x : t) ∪ K(x : t) ∪ {y = v} is consistent. If this problem is inconsistent, then v will be removed from y’s domain. In the other case, the value v for y is supported by a configuration of F (x : t) ∪ K(x : t). The exhaustive application of a procedure for maintaining global consistency requires n · d consistency checks in the worst case, where n is the number of attributes and d is the initial domain size. If a check has been positive and produced a solution, then this solution will support a value for each functional attribute. Strategies for computing diversified solutions can thus significantly reduce the number of checks. Furthermore, the procedure need not be applied to exhaustion, but may compute a lower bound for D ∗ (y) that contains only supported values and an upper bound that only excludes illegal values. Local consistency methods such as arc consistency [37] can be used to compute the upper bound. In certain cases, when the constraint network is acyclic, then arc consistency coincides with global consistency [20], meaning that the task has a polynomial cost only. For example, this condition is met if only catalog constraints are given. Configuration problems that additionally contain compatibility constraints on variables of the same catalog constraint are not acyclic and arc consistency does not remove all illegal values. Preprocessing techniques can then be used to find all solutions of K(x : t). Cluster techniques limit this preprocessing to the clusters of a cluster-tree [14, 46]. An alternative is to use decision diagrams to store the set of precomputed solutions in a factorized way [2, 29]. However, it is also possible to use suitable strategies for the consistency checks performed by the global consistency procedure. Cutset decomposition [13] and learning of strategies (detection of critical variables [36]) are good candidates for performance increases. Further speed-ups can be obtained by algorithms such as LazyAC [53] or PrefAC [5]. It should also be noted that an interactive configurator solves many configuration problems that share the same configuration model K(x : t) and that differ only in the functional requirements. Preprocessing and learning techniques can therefore pay off significantly.
24.4.2
Explanations and Relaxations
The functional requirement F (x : t) is typically a conjunction of user requirements and can alternatively be represented by a set of requirements, which will be supposed in this sub-section. If F (x : t) ∪ K(x : t) has no solution, then the configuration problem is
U. Junker
865
overconstrained and some requirements need to be relaxed. In this case, the requirements no longer express hard constraints, but desiderata that are satisfied whenever possible. There are two scenarios where such a situation can arise: 1. The user enters one requirement after the other and the interactive configurator reduces the domains of functional attributes after each entry. As the propagation might not eliminate all illegal values, the propagation can reach a dead-end. To recover from the failure, the user needs to find a minimal set of requirements for which propagation is failing, to choose a culprit from this set, and to remove it. This procedure is iterated until the set of the non-relaxed requirements is consistent. 2. The user enters multiple requirements at once, possibly augmented with a preference order. This set of requirements may be inconsistent, meaning that the configurator will compute a relaxation by removing some requirements. Removed requirements are (globally) inconsistent with respect to the selected requirements. The user needs to understand which requirements are causing the failure of a removed requirement. This explanation will allow the user to change the preferences if the removal of a requirement was not acceptable. Hence, overconstrained problems lead to a relaxation and an explanation task. Definition 24.11 (Relaxation task). Given a set of requirements F (x : t), find a maximal relaxation, i.e. a subset that is consistent with respect to the configuration model K(x : t). If additionally a strict partial order on F (x : t) is given, then find a preferred solution in the sense of [8, 33]. It is obtained by choosing a complete ranking of the requirements and by doing a lexicographic maximization based on this ranking. Definition 24.12 (Explanation task). Given an overconstrained set of requirements F (x : t), find a minimal conflict, i.e. subset that is inconsistent with respect to the configuration model K(x : t). If additionally a strict partial order on F (x : t) is given, then find a preferred conflict in the sense of [33]. It is obtained by choosing a complete ranking of the requirements and by doing an anti-lexicographic minimization based on this ranking. Relaxations are usually computed by adding one requirement after the other in the chosen order and by testing the consistency of the current selection after each step. If a solution has been found, then the requirement is kept. Otherwise, it is removed. Conflicts have traditionally been computed by truth maintenance system (TMS) [15] and several attempts have been made to integrate a TMS into a constraint solver [35, 57]. However, the computed explanations can be far from minimal, in particular if resource constraints are involved (see [33] for an example). A method for computing minimal and preferred conflicts is presented in [33]. The algorithm called QuickXplain solves the explanation problem by successively removing requirements and by checking the consistency of the remaining requirements. If the remaining requirements are inconsistent, the problem has been reduced in size. If not, then some of the removed requirements do necessarily belong to the conflict. QuickXplain is recursively dividing the explanation problem into subproblems of the same size. For example, the initial set F (x : t) will be split into two subsets C1 and C2 . It first seeks for conflict elements in C2 while keeping C1 in the background (i.e, all constraints of C1 are active, but they will not be removed while solving the second problem). The first step then
866
24. Configuration
consists in removing all elements of C2 and testing the consistency of K(x : t)∪C1 . If this fails, the empty set is a minimal conflict of the second problem, meaning that the problem has been reduced to C1 . If the test succeeds, then at least one requirement in the second problem is needed for the failure. If the second problem is a singleton, then its element is added to the conflict. If the second problem has multiple elements, it is again split into two parts and the procedure is applied recursively. When the second subproblem has been successfully solved, its minimal conflict is added to the background and the first subproblem is removed from the background. Then the first subproblem is solved. A minimal conflict for the complete problem is then obtained by merging the minimal conflicts of the first and second subproblems. Evolutions of QuickXplain have been proposed to explain the values chosen in a solution [22] and to find the parts of an overconstrained problem that need to be repaired when restoring the consistency [45].
24.4.3
Searching Solutions
Whereas interactive configurators mainly support propagation and explanation, the automatic search of solutions if an important features of configurators in manufacturing. We discuss the search of solutions for the most general form of configuration problem, which corresponds to a generative CSP. A search procedure for a generative CSP does not only need to choose a value for the different variables of the initial problem. It also needs to take into account variables that are added by inheritance or by the generation of subcomponents. These variables are added when the search procedure is making decisions about a component type or about the cardinality of a partonomic port. It is important to note that decisions about newly generated variables cannot precede the decisions that lead to their generation. As a consequence, the sequence of search decisions that produces a solution needs to respect this order. By doing this, the search configures a component by top-down refinement. The dynamic nature of complex configuration problems also contradicts some basic postulates of constraint programming that state that it is better to eliminate inconsistent choices a priori by a propagation procedure than doing this a posteriori by analyzing and learning a conflict. Configurators need to make wrong decisions in order to discover that they are wrong. For example, it is possible that a given computer type t is incompatible with respect to the given requirements. However, it may be necessary to generate all the variables and constraints that are inherited from this type in order to discover the incompatibility. This is only possible if the computer has been specialized to the type t. The conflict between the type assignment and the functional requirements that is discovered in this way provides useful information for the ongoing configuration process. Therefore, it is recommended to keep those conflicts [47]. Another issue is obtained by search decisions that choose the number of parts or that choose the functionality of the part. The search should avoid under-charged components and over-fulfilled functions. An example of under-charged components is obtained if two servers are provided for 10 users, although a single one is sufficient. Over-fulfilled functions are obtained if there is a single demand for a printing capability, but two printers are provided. Whereas over-fulfilled functions can be avoided by a suitable constraint model, under-charged components cannot be avoided by constraints. If the search procedure chooses the number of components before configuring them, it can easily end up with
U. Junker
867
under-charged components. Furthermore, it can produce under-charged components if it chooses more components than necessary or if it chooses less functionality than possible. These problems can be avoided if configurations are produced by decision sequences that respect certain properties. When a component is configured, then the following kinds of decisions should be taken in the following order: 1. First, the values for the functional attributes of the root type of the component are chosen. The functions of the component can be maximized by applying the following preferences. The presence of a capability is preferred to its absence, meaning that the value true is preferred to the value false for boolean attributes. For numerical capacities, higher values are preferred. The search procedure should then assign the best value to each functional attribute. However, trade-off considerations between multiple functional attributes allow the procedure to abandon a best value for an attribute a1 (o) if this allows an improvement for a later attribute a2 (o). The procedure can avoid a high penalization of a2 (o) by auxiliary decisions a2 (o) ≥ v that are made before assigning a value to a1 (o). As shown in [32], any Pareto-optimal combination of the attribute values can be found in this way. 2. Once the functional characteristics are chosen, the type variable is specialized by decisions of the form type ∈ leaves(t). Multiple specialization decisions can occur for the same type variable. Inherited properties and ports can be configured as soon as they are generated by such a decision. There is no predefined order among the inherited properties and ports, meaning that technical attributes, cardinalities, and connections can be configured in any order if not otherwise specified. 3. The values of the technical attributes are chosen by standard value assignments. There are no predefined preferences between these values. 4. The cardinalities of partonomic ports are chosen by decisions of the form #p(o) ≤ k and smaller values for the bound k are preferred. If such a decision fails, then its negation #p(o) > k is added to the constraints. This generates a new subcomponent p(o, k + 1) that needs to be configured before the next cardinality decision #p(o) ≤ k + 1 is tried out. The component p(o, k + 1) is configured by applying the whole configuration process recursively. 5. Connection ports are configured by membership decisions of the form o ∈ p(o). There are no predefined preferences. The task for searching a functionally well-justified solution can be expressed as follows: Definition 24.13 (Solution search task). Find a configuration that satisfies the given functional requirements and the given configuration model by a sequence of search decisions that have the form discussed above and that respect the preferences between values and variables as discussed above. Preference programming [34] proposes a language for expressing decisions and preferences for configuration problems. In addition to the structural preferences, specific preferences among the attributes of a component can be expressed as well. Whereas preference programming defines a strategy for producing a solution, other strategies may be needed to recover from a failure. Blind strategies such as min-domain-first ignore the specific
868
24. Configuration
structure of a configuration problem and do not appear to be well-adapted for this case. Strategies that move up the failure [36], cutset decomposition [13], or dependency-directed backtracking [15] are better candidates. Learning methods may also be a good way in order to identify critical variables for proving the infeasibility of a subproblem. Difficult configuration problems can also profit from symmetry-breaking methods [21]. However, the most important issue is to avoid the introduction of symmetries by the configuration model. The partonomic model presented in section 24.2.2 avoids symmetries between parts. The elements of a partonomic port are ordered and the individual elements cannot be referenced inside constraints. They are indistinguishable before being configured. A sequence of search decisions that is inconsistent for one part, will also be inconsistent for the next part. Hence, the configuration of the k + 1-st part can start where the configuration of the k-th part has stopped.
24.4.4
Satisfying User Preferences
An advanced issue in configuration is the satisfaction of user preferences. As the layman user does not know the configuration model, she or he will often run into underconstrained or overconstrained situations when specifying the requirements through the form of constraints. Underconstrained situations leave a large set of choices and there is a high risk that users miss their favorite choice. Overconstrained situations are obtained if the users choose their preferred value for each attribute. In the first case, users will not feel very confident about the obtained configuration since they have not explored the limits. In the second case, the users need to toggle through an inconsistent set of requirements and manage the preferences on their own. The need for preference handling for configuration problems has for example been expressed in [28]. Preference-based configurators offer a simple way to specify preferences in an intuitive and qualitative way. CP-nets are a successful formalism for ordering the values of an attribute dependent on the values of parent attributes [6]. Symbolic preference programming permits the user to order the requirements and to specify an order for numerical or qualitative attributes [34]. Given such preferences on multiple attributes (also called criteria), a multi-criteria optimization problem has to be solved. Although any Pareto-optimal solution of this problem may be interesting, it is often more appropriate to guide the user through the set of possible compromises by generating multiple extreme solutions (lexicographicoptimal for different rankings) and balanced solutions [32]. This approach thus generates a small set of preferred solutions of a good diversity. Diversity is ensured by changing the importance of criteria. Diversity can also be enforced by global constraints [30]. Future work on preference-based configurators is needed to develop the full potential of this feature. This includes work on algorithms, on the preference language, and on the preference elicitation methods. Explanations of failure provide a good opportunity to ask for preferences between the possible relaxations. Hence, explanations can play a key role in making preference elicitation more interactive and more efficient.
24.5 Conclusion This chapter has given an overview on constraint-based configuration while stressing the particularities of configuration. Configuration is not a classical application of Constraint
U. Junker
869
Programming. The constraint networks are not static, but evolve during problem solving. As such, the formalism of constraint networks is not sufficient to specify a configuration problem and it is necessary to go up to a higher modeling level, which describes the configuration knowledge independent of a problem-solving formalism. Configuration knowledge covers product data as found in the databases of an ERP system, structural models that can be formulated within UML or within a description logic, and the configuration constraints. The structural model includes a description of the functional characteristics and of the alternative ways to map them to a structure. Depending on the characteristics of the configured system, this knowledge can be compiled into various kinds of constraint models including boolean models, cardinality models, static and dynamic CSP models, and generative CSP models. The latter ones support dynamic activation or generation of variables and constraints and thus create new issues for the search process. The search process has to take dynamically generated variables into account and needs to respect the generation order. The search process is function-driven and should make choices only when they contribute to given functional requirements. Searching for solutions is not the only problem-solving task that occurs in configuration. Interactive configurators often support a form of (strong) propagation and let the user make the decisions. The user thus has the freedom to try out all of her or his preferred choices with the risk of running into overconstrained problems. Explanation facilities then allow the user to identify conflicting requirements, but still leave them the burden of choice. An alternative is the emerging idea of a preference-based configurator where users enter preferences among the possible values instead of making categoric choices. Preferences are heavily used in recommender systems and the lessons learned in this area may be beneficial for configuration. However, interactive configurators and their explanation facilities can also lead to new possibilities for preference elicitation, meaning that there is a potential for a cross-fertilization between both fields.
Bibliography [1]
Michel Aldanondo, Jacques Lamothe, and Khaled Hadj Hamou. Configurator and CAD: gathering the best of two worlds. In IJCAI-01 Workshop on Configuration, pages 1–14, 2001. [2] J´erˆome Amilhastre, H´el`ene Fargier, and Pierre Marquis. Consistency restoration and explanations in dynamic CSPs application to configuration. Artificial Intelligence, 135(1-2):199–234, 2002. [3] Liliana Ardissono, Alexander Felfernig, Gerhard Friedrich, Anna Goy, Dietmar Jannach, Giovanna Petrone, Ralph Sch¨afer, and Markus Zanker. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine, 24(3):93–110, 2003. [4] Virginia E. Barker, Dennis E. O’Connor, Judith Bachant, and Elliot Soloway. Expert systems for configuration at Digital: XCON and beyond. Commununications of the ACM, 32(3):298–318, 1989. [5] Christian Bessi`ere, Ana¨ıs. Fabre, and Ulrich Junker. Propagate the right thing: how preferences can speed-up constraint solving. In Eighteenth International Joint Conference on Artificial Intelligence, pages 191–196, Acapulco, 2003. [6] Craig Boutilier, Ronen I. Brafman, Carmel Domshlak, Holger H. Hoos, and David
870
[7]
[8]
[9]
[10]
[11]
[12] [13] [14] [15] [16]
[17]
[18]
[19] [20] [21]
[22] [23] [24]
24. Configuration Poole. Preference-based constrained optimization with CP-nets. Computational Intelligence, 20:137–157, 2004. James Bowen and Dennis Bahler. Conditional existence of variables in generalised constraint networks. In Ninth National Conference on Artificial Intelligence (AAAI), pages 215–220, 1991. Gerhard Brewka. Preferred subtheories: An extended logical framework for default reasoning. In Eleventh International Joint Conference on Artificial Intelligence, pages 1043–1048, 1989. David C. Brown and B. Chandrasekaran. Design problem solving: knowledge structures and control strategies. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1989. Roman Cunis, Andreas G¨unter, Ingo Syska, Heino Peters, and Heiner Bode. Plakon - an approach to domain-independent construction. In Second International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems (IAE/AIE), pages 866–874, 1989. Adnan Darwiche. New advances in compiling CNF into decomposable negation normal form. In Sixteenth European Conference on Artificial Intelligence, pages 328– 332, 2004. Johan de Kleer. An assumption–based truth maintenance system. Artificial Intelligence, 28:127–162, 1986. Rina Dechter. Enhancement schemes for constraint processing: Backjumping, learning, and cutset decomposition. Artificial Intelligence, 41(3):273–312, 1990. Rina Dechter and Judea Pearl. Tree clustering for constraint networks. Artificial Intelligence, 38:353–366, 1989. Jon Doyle. A truth maintenance system. Artificial Intelligence, 12:231–272, 1979. Alexander Felfernig, Gerhard Friedrich, and Dietmar Jannach. UML as domain specific language for the construction of knowledge-based configurations systems. International Journal of Software Engineering and Knowledge Engineering, 10(4):449 – 469, 2000. Gerhard Fleischanderl, Gerhard Friedrich, Alois Haselb¨ock, Herwig Schreiner, and Markus Stumptner. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems, 13(4):59–68, 1998. Felix Frayman and Sanjay Mittal. COSSACK: A constraint-based expert system for configuration. In Knowledge-Based Expert Systems in Engineering: Planning and Design, pages 143–166. Computational Mechanics Publications, 1987. Eugene C. Freuder. Synthesizing constraint expressions. Communications of the ACM, 21(11):958–966, 1978. Eugene C. Freuder. A sufficient condition for backtrack-free search. Journal of the ACM, 29(1):24–32, 1982. Eugene C. Freuder. Eliminating interchangeable values in constraint satisfaction problems. In Proceedings of the Ninth National Conference on Artificial Intelligence (AAAI), pages 227–233, 1991. Gerhard Friedrich. Elimination of spurious explanations. In Sixteenth European Conference on Artificial Intelligence, pages 813–817, 2004. Gerhard Friedrich and Markus Stumptner. Consistency-based configuration. In AAAI99 Workshop on Configuration, pages 35–40, 1999. Felix Geller and Michael Veksler. Assumption-based pruning in conditional CSP.
U. Junker
[25] [26] [27]
[28] [29]
[30]
[31] [32] [33]
[34]
[35]
[36] [37] [38]
[39]
[40]
[41]
871
In Eleventh International Conference on Principles and Practice of Constraint Programming, pages 241–255, 2005. Michael R. Genesereth and Nils J. Nilsson. Logical Foundations of Artificial Intelligence. Morgan Kaufmann, Palo Alto, CA, 1987. Georg Gottlob, Nicola Leone, and Francesco Scarcello. A comparison of structural CSP decomposition methods. Artificial Intelligence, 124(2):243–282, 2000. Andreas G¨unter and Christian K¨uhn. Knowledge-based configuration: Survey and future directions. In 5th Biannual German Conference on Knowledge-Based Systems, volume 1570 of Lecture Notes in Computer Science, pages 47–66, 1999. Albert Haag. Sales configuration in business processes. IEEE Intelligent Systems, 13(4):78–85, 1998. Tarik Hadzic, Sathiamoorthy Subbarayan, Rune M. Jensen, Henrik R. Andersen, Jesper Moller, and Henrik Hulgaard. Fast backtrack-free product configuration using a precompiled solution space representation. In International Conference on Economic, Technical and Organisational aspects of Product Configuration Systems, pages 131–138, 2004. Emmanuel Hebrard, Brahim Hnich, Barry O’Sullivan, and Toby Walsh. Finding diverse and similar solutions in constraint programming. In The Twentieth National Conference on Artificial Intelligence (AAAI), pages 372–377, 2005. Werner E. Juengst and Michael Heinrich. Using resource balancing to configure modular systems. IEEE Intelligent Systems, 13(4):50–58, 1998. Ulrich Junker. Preference-based search and multi-criteria optimization. Annals of Operations Research, 130:75–115, 2004. Ulrich Junker. QUICKXPLAIN: preferred explanations and relaxations for overconstrained problems. In Nineteenth National Conference on Artificial Intelligence (AAAI), pages 167–172, 2004. Ulrich Junker and Daniel Mailharro. Preference programming: Advanced problem solving for configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 17(1):13–29, 2003. Narendra Jussien, Romuald Debruyne, and Patrice Boizumault. Maintaining arcconsistency within dynamic backtracking. In Sixth International Conference on Principles and Practice of Constraint Programming, pages 249–261, 2000. Olivier Lhomme. Quick shaving. In Twentieth National Conference on Artificial Intelligence (AAAI), pages 411–415, 2005. Alan K. Mackworth. Consistency in networks of relations. Artificial Intelligence, 8(1):99–118, 1977. Alan K. Mackworth, Jan A. Mulder, and William S. Havens. Hierarchical arc consistency: exploiting structured domains in constraint satisfaction problems. Computational Intelligence, 1:118–126, 1985. Diego Magro and Pietro Torasso. Decomposition strategies for configuration problems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 17(1):51–73, 2003. Daniel Mailharro. A classification and constraint based framework for configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4):383–397, 1998. John P. McDermott. R1: A rule-based configurer of computer systems. Artificial Intelligence, 19:39–88, 1982.
872
24. Configuration
[42] Deborah L. McGuinness and Jon R. Wright. Conceptual modelling for configuration: A description logic-based approach. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4):333–344, 1998. [43] Sanjay Mittal and Brian Falkenhainer. Dynamic constraint satisfaction problems. In Eighth National Conference on Artificial Intelligence (AAAI), pages 25–32, 1990. [44] Sanjay Mittal and Felix Frayman. Towards a generic model of configuration tasks. In Eleventh International Joint Conference on Artificial Intelligence, pages 1395–1401, 1989. [45] Barry O’Callaghan, Barry O’Sullivan, and Eugene C. Freuder. Generating corrective explanations for interactive constraint satisfaction. In Eleventh International Conference on Principles and Practice of Constraint Programming, pages 445–459, 2005. [46] Bernard Pargamin. Extending cluster tree compilation with non-boolean variables in product configuration: A tractable approach to preference-based configuration. In IJCAI-03 Workshop on Configuration, pages 32–37, Acapulco, Mexico, 2003. [47] Charles J. Petrie. Constrained decision revision. In Tenth National Conference on Artificial Intelligence (AAAI), pages 393–400, 1992. [48] Jean-Franc¸ois Puget. PECOS: a high level constraint programming language. In Proceedings of the 1st Singapore International Conference on Intelligent Systems (SPICIS’92), pages 137–142, Singapore, 1992. [49] Raymond Reiter. A theory of diagnosis from first principles. Artificial Intelligence, 32:57–952, 1987. [50] Daniel Sabin and Eugene C. Freuder. Configuration as composite constraint satisfaction. In George F. Luger, editor, Proceedings of the Artificial Intelligence and Manufacturing Research Planning Workshop, pages 153–161. AAAI Press, 1996, 1996. [51] Daniel Sabin and Rainer Weigel. Product configuration frameworks - a survey. IEEE Intelligent Systems, 13(4):42–49, 1998. [52] Mihaela Sabin, Eugene C. Freuder, and Richard J. Wallace. Greater efficiency for conditional constraint satisfaction. In Ninth International Conference on Principles and Practice of Constraint Programming, pages 649–663, 2003. [53] Thomas Schiex, Jean-Charles R´egin, Christine Gaspin, and G´erard Verfaillie. Lazy arc consistency. In Thirteenth National Conference on Artificial Intelligence (AAAI), pages 216–221, 1996. [54] Patrik Simons, Ilkka Niemel¨a, and Timo Soininen. Extending and implementing the stable model semantics. Artificial Intelligence, 138(1-2):181–234, 2002. [55] Carsten Sinz, Andreas Kaiser, and Wolfgang K¨uchlin. Formal methods for the validation of automotive product configuration data. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 17(1):75–97, 2003. [56] Timo Soininen, Esther Gelle, and Ilkka Niemel¨a. A fixpoint definition of dynamic constraint satisfaction. In Fifth International Conference on Principles and Practice of Constraint Programming, pages 419–433, 1999. [57] Mohammed H. Sqalli and Eugene C. Freuder. Inference-based constraint satisfaction supports explanation. In Thirteenth National Conference on Artificial Intelligence (AAAI), pages 318–325, 1996. [58] Markus Stumptner. An overview of knowledge-based configuration. AI Communications, 10(2):111–125, 1997. [59] Markus Stumptner, Gerhard Friedrich, and Alois Haselb¨ock. Generative constraint-
U. Junker
[60]
[61]
[62]
[63] [64]
[65]
873
based configuration of large technical systems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4):307–320, 1998. Markus Stumptner and Alois Haselb¨ock. A generative constraint formalism for configuration problems. In Advances in Artificial Intelligence, Third Congress of the Italian Association for Artificial Intelligence, AI*IA’93, pages 302–313, 1993. Gruber T., Olsen G.R, and Runkel J.T. The configuration design ontologies and the VT elevator domain theory. International Journal of Human-Computer Studies, 44(4):569–598, 1996. Erlendur S. Thorsteinsson and Greger Ottosson. Linear relaxations and reduced-cost based propagation of continuous variable subscripts. Annals of Operations Research, 115:15–29, 2002. Rainer Weigel and Boi Faltings. Compiling constraint satisfaction problems. Artificial Intelligence, 115(2):257–287, 1999. Brian C. Williams. Interaction-based invention: Designing novel devices from first principles. In Proceedings of the Eighth National Conference on Artificial Intelligence (AAAI), pages 349–356, 1990. Katariina Ylinen, Tomi M¨annist¨o, and Timo Soininen. Configuring software products with traditional methods - case LINUX family. In ECAI-02 Workshop on Configuration, pages 17–22, 2002.
837
Chapter 24
Configuration Ulrich Junker Configuration is the task of composing a customized system out of generic components. This task is of concern to everybody as component-based systems are omnipresent in modern industry. Prominent examples of component-based systems are computers, home cinemas, cars, and trucks. Classic examples are kitchen and furniture that can be assembled from a given catalog of components. As the need for customization is growing, more and more products follow the pattern of a component system. New examples are service packs such as telecommunication offers, loans and insurance products, but also travel packages and other examples from the service industry. Finally, we should not forget componentbased software systems. Components are generic in nature and can be produced in mass, but are destined to support customized solutions. The available components for a given type of system are usually described in the form of a catalog. Each catalog item is a product type and describes the functional and technical characteristics of the component. For example, take a printer component. The function is printing. The functional characteristics include printing quality and support of colors. The technical characteristics include printing type (laser, jet) and printing speed. Whereas the catalog describes the generic knowledge of components, a customer usually has specific requirements for the desired component-based system. For example, the customer wants to set up a home movie studio that allows the filming, editing, and showing of movies and optionally the printing of snapshots and insertion of photos. To match the specific customer requirements, a configuration of the components needs to be determined. A configuration is a set of instances of the available component types that are customized and combined to meet the requirements. A configuration for the home movie studio consists of a video camera with analog output, a video recorder with analog input, and a TV screen. Another configuration consists of a video camera with digital output, a computer with a card for digital video capture, software for video editing, a DVD reader/writer, a printer, and a scanner. The task of finding a suitable configuration encounters several difficulties. Firstly, there can be a huge number of configurations responding to the customer requirements. The
838
24. Configuration
number of alternatives may be large even if a single component needs to be chosen. The customer usually is not satisfied with an arbitrary choice, but has preferences on multiple criteria of the catalog items such as the color or seat material of a desired car. Hence, a configuration problem may correspond to a multicriteria decision-making problem. Normally, a configuration does not consist of a single component, but multiple components. Car configuration problems allow the choice of multiple options that are subject to technical constraints. For example, the choices of a roof rack and of a cabriolet are incompatible. In this case, the configuration problem is a combinatorial problem. In more complex examples such as the configuration of instrumentation and control systems, the number of required components is initially unknown. The problem space of the configuration task then contains a possibly infinite number of candidate configurations. Universally quantified constraints can be used to represent knowledge about unknown parts and we obtain a satisfiability problem in a (decidable) fragment of first-order logic. Finally, a configuration problem can be large in size and involve huge numbers of product types and constraints. Complex configuration problems are, for example, encountered in the engineering and manufacturing departments of the computer and automotive industries, which need to complete customized sales orders by choosing suitable parts from huge catalogs. This situation has led to the development of configurators that do this completion automatically while respecting difficult technical constraints. However, configurators can also support the sales process and assist the user in choosing options while guaranteeing their compatibility. Although the first configurators were based on production rules, Constraint Programming (CP) nowadays appears to be the method of choice for solving diverse forms of configuration problems. CP addresses the complete space of possible configurations, no more and no less. End users can formulate arbitrary requirements without taking the risk that their favorite configurations are forgotten. CP handles the combinatorial aspects of configuration problems. CP is able to discover unforeseen interactions between different components and constraints thanks to propagation, search, and learning algorithms. CP can also profit from existing expertise in solving configuration problems by using it for guiding the search. However, classic CP methods lacked appropriate techniques to represent complex configuration knowledge, to reason about an unknown number of components, to handle user preferences, or to provide explanations when interactive solving ran into failure. Specific research on constraint-based configurators has addressed those points by incorporating techniques from fields such as knowledge representation, theorem proving, and preference handling. This handbook chapter gives a survey of the main techniques. Section 24.1 explains the diversity of configuration problems and extracts specific challenges for CP. Section 24.2 distinguishes different kinds of knowledge used in configuration problems, which can be used to build rather different constraint models as explained in section 24.3. Section 24.4 presents the problem-solving tasks occurring in configuration.
24.1 What Is Configuration? 24.1.1
A Whole Spectrum of Problems
Configuration has been an outgrowth of research on rule-based expert systems. John McDermott [41] used the term configuration for a specific form of a design task [9], where a system was assembled out of predefined components that are connected in predefined
U. Junker
edit system ......... .... .... ...
Home Movie Studio
filming capability editing capability show capability
...
Video Editing software...... ...... ..... Software 1..1
839
... devices ....... ....... ...
edit capacity video file format
... computer ....... ..... ...
0..1 Video Editing System
Device 0..n ... .. ..... ..... ..... .... .... .... .... .... .... .... ....
Camera
1..1
DVD Player
..
... ... disks Computer ............. 0..n
storage capacity
TV
Hard Disk
Figure 24.1: Component types of a home movie studio.
ways. Whereas more innovative design tasks often require a suitable modeling of the physical behavior of components [64], work on rule-based configurators focused on the functional aspects of components. Frayman and Mittal summarized those approaches by a general definition of the configuration task [44] and thus provided a foundation of the field of configuration similar to Reiter’s for the fault diagnosis in technical systems [49]. The essence of this definition is as follows: A configuration problem is characterized by two constituents: 1. A catalog which describes the generic components in terms of their functional and technical properties and the relationship between both. 2. User requirements and user preferences about the functional characteristics of the desired configuration. The configuration task consists of finding the following answer: 1. One or more configurations that satisfy all requirements and that optimize the preferences if those requirements are consistent. 2. An explanation of failure in the other case. A configuration is a set of customized components together with a description of their connections. A component itself is defined by its type, its attributes, and its subcomponents. Attributes may express functional properties such as filming capability or edit capacity in terms of filmed hours (see Figure 24.1). However, attributes may also express technical properties that describe how a given functional property is achieved. For example, the video file format (AVI, MPEG2) used for editing and the storage capacity are technical characteristics. If a given functional property is fulfilled by a single component, then this component is primitive and has no subcomponents. In the movie studio example, a video camera directly realizes the filming functionality. However, a function may also be fulfilled by a combination of components. The combination can be achieved by a composite component that has subcomponents. For example, the storage capacity of a movie studio system may be supplied by a computer as well as the external disks of the computer, which thus all together achieve the required edit capacity. The combination can also be achieved by an architecture that defines how components need to be combined to fulfill the function. For example, the home movie studio may have a video editing system, which consists of a computer, editing software, and other components such as a video capture card and a video
840
24. Configuration
recording facility. This video editing system is not a component that can be chosen from a catalog, but a ‘functional unit’ that describes how other components need to be combined for the purpose of video editing. The general description of the configuration task covers a large spectrum of concrete configuration problems and can be simplified depending on the application domain and the purpose of the configurator. As explained in [28, 51], it is useful to distinguish configuration for sales and configuration for manufacturing and engineering. Sales configurators address the needs of laymen in business-to-customer applications (B2C) or buyers in business-to-business applications (B2B). Components are described in terms of sales categories and correspond to items that customers can order. Their level of detail is much smaller than that of the parts that can be manufactured. The result of the sales configuration can be used as input for a technical configurator that checks whether the ordered system can be produced. The configurator uses existing product models in the form of billof-materials and compatibility tables and chooses a structure and the parts of the product. Whereas sales configurators are highly interactive and user-driven, manufacturing requires configurators that automatically complete given requirements. The structure of a configured system depends on the application domain. A car configuration usually consists of a small number of features. A configured computer is typically described by a small hierarchy of parts. A custom kitchen may have an unbounded number of parts. An instrumentation-and-control system may additionally require that an unbounded number of parts is packed into an unknown number of racks and boards. This difference in structure explains why so many different techniques have been applied to configuration problems. A first survey of configuration techniques given by [51] distinguishes rule-based reasoning [41], model-based reasoning [44], and case-based reasoning for configuration. The model-based branch covers approaches based on description logic [42], constraint programming [43, 59], and resource models [31]. The survey now needs to be completed by approaches based on SAT [55], binary decision diagrams [29], integer programming [62], and also answer-set programming [54]. Furthermore, there have been various attempts to combine several techniques in order to enhance the modeling and solving capabilities of a configurator. The diversity of techniques is confirmed by other surveys [27, 58]. Independent of the problem and the approach, a configurator needs to address the following requirements concerning problem solving: 1. Generation of components to carry out the functional requirements. 2. Reasoning about the interactions of multiple components. 3. Detection of cases where the desired functionality cannot be implemented. A further requirement concerns modeling. The configurator needs to provide a high-level modeling language that allows the configuration expert to model complex systems and to maintain these models. Rule-based approaches represent functional requirements in terms of assertions in the working memory and map them to components through rules. A rule for selecting a component is fired if there is a requirement needing this component. When executed, a rule can generate new components, customize existing components, or add subcomponents. Depending on the context, the same function may be achieved differently, meaning that we obtain multiple rules of the form:
U. Junker
841
if function and context 1 and constraints okay then component 1 ... if function and context m and constraints okay then component n The rule conditions need to check possible interactions with other components and may become very complex. If compatibility constraints between components are changing, then they need to be incorporated into the conditions of multiple rules. This lack of modularity caused a severe maintenance problem in the R1/XCON configurator of DEC computers [41, 4]. Furthermore, rule-based systems usually do not have the capability of detecting cases that cannot be achieved by the given catalog. Nevertheless, rule-based systems may be useful for very simple configuration problems requiring a small number of choices only. Model-based reasoning addresses the deficiencies of rule-based reasoning. Firstly, it separates the problem description from the solving algorithm, thus allowing an analysis of the problem independent of the chosen approach. Secondly, it requires that the problem description is based on a model of the system to be configured. This model consists of decomposable entities and the interactions between these elements. Modularity or composability is thus well-addressed since components can easily be added or removed without changing the whole model. Thirdly, it requires that this problem description is complete and defines a closed space of possible configurations. If no element of this space satisfies the given requirements, then the problem has no solution. Description logic (DL) is well-suited to describe component types and their relations. It organizes components types in a taxonomy. Description logic allows us to define complex types out of primitive types. It is able to detect specialization relations between complex types and to test the consistency of types by a process called classification. Classification can be used to solve configuration problems if the configuration knowledge can be completely expressed in the description logic. In most cases, the expressiveness of the description logic is not sufficient and a rule-based or constraint-based engine is used in addition to deal with complex compatibility and numerical constraints. Such a hybrid approach has, for example, been pursued in the CLASSICS-project [42] and in the PLAKON-project [10]. DL-based configurators have been applied to the configuration of telecommunication equipment [42], elevators [61], passenger cabins in aircrafts [27], and many other systems that have a complex structure. They also address the problem of generating a hierarchy of parts and can exploit this hierarchy for problem decomposition [39]. Resource-based approaches [31] are dedicated to complex equipment configuration problems where components provide and consume given resources. For example, the storage devices of a computer system provide storage capacity, but they consume power and slots. The slots are provided by the racks of the computer system. The purpose of the resource-based configuration process is to bring produced and consumed resources in balance, meaning that the consumed resource does not exceed the produced resource. The process starts from initial resource requirements such as a minimal storage capacity, which are consumed from outside and which need to be produced by generating and customizing suitable parts. The resource-based approach is necessary for many configuration problems, but is not sufficient on its own. As such, it is best integrated with other approaches. Constraint satisfaction problems (CSP) are well-suited to defining a closed space of configurations. They use variables with domains. If the number of variables is fixed, then the space is obtained as the Cartesian product of the domains. Constraints also handle the interaction of multiple components. Compatibility constraints specify which components
842
24. Configuration
can be combined. Aggregation constraints (such as sums) are able to deduce global properties such as the produced or consumed amount of a resource. Variables express the possible choices for fulfilling a functional requirement. Since the choice should only be made if the requirement is present, we obtain a conditional disjunction of the form: if function then component 1 or ... or component n The disjunction is encoded by a variable x having as domain the components that can be chosen. However, this variable should only be introduced if the function is indeed required and this may depend on other choices. Hence, new variables and constraints may be activated or generated during the problem solving. A rule-based constraint engine can add new constraints when executing rules and retract them during search thanks to a truth maintenance system (TMS) [15, 12]. For example, the configurator in [28] is based on a TMS. However, the dynamic nature of configuration problems provides a particular challenge for Constraint Programming approaches that maintain local consistency during search. Mittal and Falkenhainer therefore introduced Dynamic CSPs (now called Conditional CSPs) which have optional variables and constraints. Local consistency algorithms for Conditional CSPs have been elaborated in [43, 52]. Stumptner and Haselb¨ock [60, 59, 17] introduced resource-based reasoning into CP and Mailharro [40] extended it with cardinalitybased reasoning. The CP approach has successfully been applied to the configuration of cars, computers [18], instrumentation and control systems [40], web services [3]. SAT approaches can be seen as a special case of CP. They mainly handle requirement and compatibility constraints, but no numerical constraints such as resource constraints. They have successfully been applied to car configuration [55]. Answer-set programming [54] formulates configuration knowledge through form of default rules, while ensuring functionally well-justified configurations through groundedness conditions [56]. This approach has been applied to software configuration [65]. Interactive sales configurators are simultaneously solving the configuration problems of multiple customers and require rapid response times. As these problems differ only in the requirements, but not in the catalog, preprocessing techniques can be used to compute configurations in advance. For problems involving a fixed number of parts with small finite domains, it may be possible to represent the whole configuration space compactly by a binary decision diagram [29], an automaton [2], or the decomposable negation normal form [11]. Other knowledge-compilation techniques include synthesis trees [63] and clustertrees [14, 46]. All these techniques are compatible with respect to a CP approach. Knowledge compilation has successfully been applied to car configuration problems [29, 46]. CP is well-suited to define a clear configuration space. It ensures composability by treating interactions between arbitrary components and by deriving global properties of sets of components. It also offers a high freedom in modeling and the modeling is completely declarative. Thus, CP meets the requirement for an expressive and maintainable modeling capability that has been stated above. All these advantages made it the method of choice for configuration. However, configuration problems posed several challenges to CP which are summarized in the next sections.
24.1.2
Modeling Challenges for CP
Most applications of Constraint Programming (CP) concern real-world systems that are modeled in an object-oriented way. CP addresses the combinatorial aspect of the applica-
U. Junker
843
tion to be solved. It is often possible to isolate this aspect by generating a constraint model from the given object model. For example, a production plan in a scheduling application is translated into a set of start- and end-time variables and precedence constraints. The object model can be completely ignored when solving the scheduling problem. However, this complete separation of object model and constraint model is not possible for configuration problems, which poses new challenges for the modeling and the modeling language: Product catalogs: Configurators need to be deeply embedded in business processes and reuse existing product models in order to facilitate modeling and maintenance. Existing product catalogs in the form of database tables need to be mapped to constraint models. Since they strongly influences the structure of the constraint model, they cannot be ignored when discussing constraint models for configuration. Knowledge representation: Knowledge of the component structure is usually represented in the form of a taxonomy of component types. More specific types add attributes, domain restrictions, and subcomponents. Whereas object-oriented programming assumes that the type of an object is static, it is represented as a variable in constraint-based configuration. Constraint reasoning can specialize the component by reducing the domain of the type variable. The component then inherits the properties of the more specialized types during the solving process, which leads to the activation of new variables and constraints. The constraint engine has to support this inheritance process. Resource constraints: The number of parts of a configuration may not be bounded, but depends on global resource requirements. Hence, the set of components is not given in this case, but has to be determined as a result of the configuration task. In order to express constraints on those unknown parts, universally quantified constraints are necessary. Furthermore, variables representing the choice of an unknown part will have an open domain that is extended during constraint solving. Constraints on variables with open domains such as resource constraints need to deal with this situation. Preference models: A further challenge is obtained by the potentially huge set of solutions. Since these solutions differ much in their characteristics, user preferences need to be taken into account when solving the configuration problem.
24.1.3
Problem Solving Challenges for CP
The solving process faces additional challenges that depend on the type of the configuration problem. Configurators for manufacturing and engineering need to handle the following issues in addition to normal solving strategies for CP: Top-down refinement: a search strategy for finding a configuration cannot make decisions in an arbitrary order, but needs to implement top-down refinement that configures components before their subcomponents and that specializes the type variable before instantiating inherited attributes. Component generation: resource requirements may require the generation of an unbounded number of parts. Generation steps need to be incorporated into the solving strategy. A careful control of the generation is needed in order to avoid cyclic reproduction of the same state and to avoid the inclusion of parts that do not fulfill any function. Although interactive sales configurators are treating much simpler problems, they are facing challenges as well: User Scalability: web-based configurators need to solve many similar problems and this within short response times. It is therefore reasonable to share information between
844
24. Configuration
different threads (e.g. learning of strategies, conflicts, and solutions) or to preprocess the catalog by knowledge-compilation techniques. Explanations: interactive configurators let the user make the choices. As the user may easily encounter over-constrained problems, an explanation of failure in the form of conflicting requirements is needed. An explanation facility is a critical feature for an interactive configurator. Preference elicitation: interaction cycles can be shortened if the configurator remembers or acquires user preferences. The configurator can thus offer a preferred solution and automatically reactivate preferred choices when the user takes back options that are in conflict with those choices.
24.2 Configuration Knowledge This section introduces the knowledge that exists about components, namely component catalogs in sub-section 24.2.1, component structure in sub-section 24.2.2, and component constraints in sub-section 24.2.2. It introduces the different ingredients of a component such as functions (features), attributes, subcomponents and connections, and resources and provides the basic vocabulary for formulating constraint models.
24.2.1
Configuration Catalog
The literature distinguishes a large variety of configuration problems. In spite of this diversity, all those problems are based on the notion of a primitive component that does not contain subcomponents and that directly fulfills a required function. Each primitive component has a concrete type and a set of attributes describing the functional and technical characteristics of the component. Functional characteristics are either capabilities which are described by boolean attributes (such as printing) or capacities which are described by numerical attributes (such as storage capacity). A concrete type is a product type that can be ordered by the customer (in the case of a sales configurator) or that can be produced (in the case of a configurator for manufacturing). The technical characteristics are represented by further attributes that are either uniquely specified for the concrete type or that have multiple options. A primitive component is thus characterized by its type and the values of its attributes. Knowledge about the available primitive components is available in the form of product catalogs. The product catalogs are an integral part of enterprise resource planning (ERP) systems that support engineering and manufacturing. As it is important to embed configurators into those business processes, configurators need to reuse existing product models to facilitate modeling and maintenance. The product catalogs are available in the form of database tables. Each table describes a technical (component) type. There may be a table for hard disks, another one for video cameras, and another one for DVD players. A technical type defines the functional and technical attributes of a component, but does not specify the values for those characteristics. A technical component can be realized by multiple concrete (component) types. A concrete type specifies a concrete value for each attribute or gives the set of possible attribute values. For example, a concrete screen type may have a fixed size or a small set of possible sizes. The set of possible values can be expressed by an enumeration of values or by a range of two numerical bounds. The domain
U. Junker
845
Table 24.1: Catalog (video camera). Type cam1 cam2 cam3 cam4
Output analog AVI anal.+AVI. AVI
Input none none AVI AVI
price 200 300 400 500
of an attribute for a concrete type can thus be a singleton, an interval, or an enumeration of values. Whereas a single database column is sufficient for singleton domains, two columns are needed to represent interval domains. Attributes with enumerated domains may be represented by further tables. As a consequence, a product catalog in the form of a database does not directly reflect the product model. Annotations of the database are needed to interpret them in terms of a product model and to transform them into the following form: Definition 24.1 (Catalog knowledge). A configuration catalog is described by a set T of technical types, a set L of concrete types (the leaf types), and a set A of attributes that are all mutually disjoint. Each technical type t in T has a set attrs(t) ⊆ A of attributes and a (non-empty) set subtypes(t) ⊆ L of concrete types. The set of leaf types of two different technical types are mutually disjoint. Each technical type t has a table which defines a domain D(a, t ) for each attribute a ∈ attrs(t) and each product type t ∈ subtypes(t). Table 24.1 describes the catalog of video cameras. The first column describes the camera type. The other columns specify the values for the input and output formats and the price. This catalog is important when setting up a constraint model. Firstly, it provides the domains for the variables that are introduced for attributes. Secondly, it defines a constraint between the concrete type of a component and its attributes. We call this the catalog constraint. This constraint expresses a relationship between functional requirements and the technical characteristics of a primitive component, including its type. Given a user requirement on a functional property (e.g. a maximal price of 300), local consistency methods will remove all concrete types that are unable to provide this property (such as the camera types cam3 and cam4). As a consequence, the remaining types are able to meet this functional requirement. Thus, existing product models yield an important part of a constraint-based configuration model. Catalog constraints are particularly important since they are able to classify a component by reducing the domain of its type variable.
24.2.2
Partonomies and Taxonomies
Whereas sales configurators often deal only with primitive components, manufacturing and engineering needs to refine those components by suitable parts. The part-of-structure of components is therefore of central importance for configuration. A composite component has a concrete type, a set of attributes, and a set of subcomponents (or parts), which may be primitive or composite components. Following [16, 39], it makes sense to stipulate that components own their subcomponents. Hence, a subcomponent cannot be a part of two different components. Furthermore, the part-of-relation between components must neither contain cycles, nor infinite descending chains. A (sub)-
846
24. Configuration
camera
Home Movie Studio
... ....... ....... ... ... ....... ....... ...
1..1
computer
0..1
Camera
Computer
.... ...... ...... disks ...
1..n
Hard disk
Figure 24.2: A partonomy of functional and technical types.
component may also have a set of connections to other (sub)-components of the configuration. There are no restrictions concerning connections. Subcomponents as well as connected components can be grouped together into subsets of components, which are called ports in [44]. A port contains components that are functionally equivalent for the given problem. We distinguish partonomic ports that contain subcomponents and connectionports that contain connected components. Partonomic ports own their elements and are mutually disjoint. The structure of a composite component is defined by a structural product model. The partonomy describes the possible decompositions of components of a given type. Figure 24.2 shows the partonomy of a simple home movie studio. It consists of a camera and an optional computer which can have several hard disks. Such a partonomy can be complemented by a ‘topology’, which defines the connections between components and which consists of arbitrary relations between the types of a partonomy. Product models in ERP systems contain information about the partonomy. The bill-ofmaterial (BoM) describes how many subcomponents of which type are needed to assemble or to manufacture a component. A BoM is represented by a graph. The nodes are component types. The edges represent has-Part-relations and are labeled with a cardinality. An edge from type t1 to type t2 with label k means that a component of type t1 contains k subcomponents of type t2 . It can be assumed that a bill-of-material of configurable products is a directed acyclic graph. A BoM can easily be translated into a partonomy. Each node in the BoM corresponds to a technical type and each edge from type t1 to type t2 with label k in the BoM is translated into a 1 : k-relation from t1 to t2 . Concrete types specify or restrict the attribute values of a component. They may also specify the number of parts of a component (e.g. the number of wheels of a car). Technical types define the functional and technical attributes and the component structure. They regroup together multiple concrete types. However, it makes sense to further regroup technical types according to their functional characteristics. For example, the device for storing an edited movie can be a hard disk, a DVD writer, or a video recorder, or the camera itself. It therefore makes sense to regroup these technical types under a functional type called storage device. This functional type defines functional attributes such as a writing capability and the storage capacity. We thus obtain a taxonomy of types that consists of three layers: 1. A hierarchy of functional types. 2. A layer of technical types. 3. The leaf layer of concrete types. It is then possible to create an instance of a functional type, such as a storage device, and to configure it by specializing its type. This process will add new attributes to the component and refine its structure incrementally. A taxonomy thus describes alternative ways to map functional requirements to structure and to refine structural skeletons. Partonomies with taxonomies correspond to bill-of-materials with alternatives. Figure 24.3 shows the partonomy of the
U. Junker
Functional 0..n Unit ... ... ... .. ... ..... .. ... ..... ..... .....
Film Unit
...... ... ...
Manual
Edit Unit ..
.. .. ... ....
... ....... ....... ...
Home Movie Studio total price
Manual
edit capacity edit format
.............
Device ..... .... ....
Computer
Video Device.. ..
0..n .. .. ... .... Hard Disk storage capacity
..... .... ....
Computer− based
computer
0..n devices
... ....... ...... ... disks
... ....... ....... ...
1..1
Show
...........Unit ..... . .... ...
Computer−............. . . based .....
functions
847
DVD
.. .. ... ....
Camera
output format input format
Video
Recorder
Figure 24.3: A partonomy with taxonomy.
home movie studio which consists of functional units and devices. The functional units describe how the filming, editing, showing functions are realized. The edit and show unit can be manual or computer-based. Depending on these choices, different kind of devices need to be added. There is also a connection port indicated by a dashed line. A partonomy with a taxonomy can be represented in the form of a UML-diagram [16] or by a description logic. We define the structure of a component independent of a formal language: Definition 24.2 (Structural knowledge). A structural configuration model consists of a set Tˆ of functional types, a set T of technical types, a set Aˆ of attributes, a set Pˆ of partonomic ˆ of connection ports, all mutually disjoint: ports, and a set of Q 1. Each functional type t ∈ Tˆ has a (possibly empty) set subtypes(t) ⊆ Tˆ ∪ T of direct subtypes. The set of direct subtypes of two types are mutually disjoint meaning that each type has at most one direct supertype. 2. Each functional or technical type t in Tˆ ∪ T has a set attrs(t) ⊆ Aˆ of attributes ˆ of partonomic and connection ports. Each port p has a and a set ports(t) ⊆ Pˆ ∪ Q destination type type(t, p) ∈ Tˆ ∪ T , a minimal cardinality min(t, p), and a maximal cardinality max(t, p). 3. There is no sequence t1 , . . . , tn of types in Tˆ ∪ T such that t1 = tn and ti is a subtype of ti−1 or the destination type of a partonomic port of ti−1 . A structural configuration model can be extended by a configuration catalog if both coincide in their technical types as well as in the attributes attrs(t) of each technical type. A configuration can be obtained from a structural model by instantiating a component type. Table 24.2 shows the instance ourStudio of the Home Movie Studio which inherits the attributes and ports of this type. The attributes are assigned to values from the attribute domain and the ports are filled by part lists. For each part, a type is chosen and the part inherits the attributes and ports of this type, meaning that this process is repeated recursively. Hence, a structural configuration model generates a nested data structure when being instantiated. This data structure is central for the modeling and solving of configuration problems. In the remainder of this chapter, we need to refer to different elements of this data structure. Firstly, we will define a view on all the parts of the
848
24. Configuration Table 24.2: A configuration. ourStudio: a Home Movie Studio . total price: 2000 $ . functional units: . . unit(ourStudio,1): a Film Unit . . unit(ourStudio,2): a Computerized Video Edit Unit . . . edit capacity: 20 hours . . . edit format: AVI . . . computer: device(ourStudio,2) . devices: . . device(ourStudio,1): a Cam4 Camera . . . output format: AVI . . . input format: AVI . . device(ourStudio,2): a Computer . . . external hard disks . . . . disk(device(ourStudio,2),1): a Hard Disk . . . . . storage capacity: 120 GB . . . . disk(device(ourStudio,2),2): a Hard Disk . . . . . storage capacity: 160 GB
(an attribute) (a partonomic port) (a part) (a part)
(a connection port) (a partonomic port) (a catalog part)
(a catalog part) (a partonomic port) (a catalog part) (a catalog part)
component. This view includes also the indirect parts, i.e. the parts of the parts of the component and so on. In the example, the part view contains ourStudio, unit(ourStudio,1), unit(ourStudio,2), device(ourStudio,1), device(ourStudio,2), disk(device(ourStudio,2),1), disk(device(ourStudio,2),2). The part view contains all parts that are generated for a configuration. This information will be needed when we model connection ports as these ports are filled with the generated parts. Secondly, we define a view on all ports of a component. This includes the direct ports of a component, but also the ports of all components that are contained in a given port. As a port describes a set of parts that play the same role in a configuration, most configuration constraints are formulated with the help of ports. For example, if we want to sum the storage capacities of all the hard disks of the home movie studio, we need an indirect port that contains all the hard disks of the studio. Thirdly, we introduce a view on the properties of a direct or indirect port. An example is the storage capacities of our indirect hard disk port. In addition to the attributes, we include other properties, namely the types and the port cardinalities. All these properties can be subject to constraints. The property view is thus essential for the formulation of constraint models. All three views need to have counterparts in an expressive modeling language. We will define all the three views for an anonymous instance of a component type t. Not only does this instance inherit attributes and ports from the direct supertype super(t) i of t, but also from the indirect supertypes super∗ (t) := ∞ i=0 super (t). As the anonymous component can be specialized to any subtype of t, we take also attributes and parts of all the subtypes of t into account when defining the views. The direct and indirect subtypes are contained in subtypes∗ (t) := {t ∈ Tˆ ∪ T ∪ L | t ∈ super∗ (t )}. As components need to be ˆ specialized to leaf types, we also define the set of leaf types leaves(t) := subtypes∗ (t) ∩ L ˆ includes the types from Tˆ, T , and L that have no subtype. where L Now we formally define the part view. The set parts(x : t) of direct parts of a component x of type t is the smallest set which satisfies the following properties: 1. If p is a single-valued partonomic port of a type in super∗ (t) or subtypes∗ (t) then the port has a unique part p(x) in parts(x : t) which is an instance of the port’s destination type.
U. Junker
849
2. If p is a multi-valued partonomic port of a type in super∗ (t) or subtypes∗ (t) then the port has multiple parts p(x, 1), p(x, 2), p(x, 3), . . . in parts(x : t), which are all instances of the port’s destination type. If a set X of components is given, then their parts are determined by the element-wise application of the parts-function and we obtain the set of all direct and indirect parts of x by taking the reflexive and transitive closure: ∞ parts(X) := parts(x : t) and parts∗ (x : t) := partsi ({x : t}) (24.1) x:t∈X
i=0
The infinite set parts∗ (x : t) contains all potential parts for a component x. A configuration of the component x consists of a finite subset of this part universe. Next we define the port view. The set of ports ports(x : t) of a component x of type t is the set of all ports p(x) such that p is a (partonomic or connection) port of a type in super∗ (t). The set of ports of multiple components is obtained by the element-wise application of this operator. The reflexive and transitive closure defines the port view of x: ∞ ports(X) := ports(x : t) and ports∗ (x : t) := portsi ({x : t}) (24.2) x:t∈X
i=0
Each element p1 (p2 (. . . pk (x))) of ports∗ (x : t) has a minimal cardinality that is obtained by multiplying the minimal cardinalities of all the pi ’s and a maximal cardinality that is obtained by multiplying the maximal cardinalities of all the pi ’s. If the maximal cardinality is strictly greater than 1 then the port is called multi-valued. If the maximal cardinality is equal to 1 then it is called single-valued. If the minimal cardinality of a single-valued port is 0 then this port is called optional. Finally, we define the property view. The set props(x : t) of properties of a component of type t is the smallest set that has the following properties: 1. The leaf type type(x) of component x is in props(x : t). 2. If a is an attribute of a type in super∗ (t) then the attribute a(x) of x is in props(x : t). 3. If p is a multi-valued port of a type in super∗ (t) then the cardinality #p(x) of the port p(x) is in props(x : t) The set of properties of multiple components is obtained by the element-wise application of this operator: props(X) := props(x : t) (24.3) x:t∈X
Given this, we introduce the properties props(ports∗ (x : t)) of the component and of all its direct and indirect ports. A property of a single-valued port is called single-valued, that of a multi-valued port is called multi-valued, and that of an optional port is called optional. The constraint model needs to take into account the knowledge of the component structure. If an instance of a functional type is configured, then its type variable has all leaf types of the functional type as possible values. When constraint propagation reduces the domain of this variable, it automatically classifies the component, meaning that the component now belongs to a more specialized type. It then needs to inherit the properties of the specialized type. These properties can require further choices, meaning that new variables and their constraints need to be included in the constraint model. Constraint models that model this inheritance reasoning are therefore dynamic or conditional (see section 24.3.4).
850
24. Configuration Table 24.3: Compatibility of storage device and video format. Storage device hard-disk hard-disk DVD VCR Digital Camera Analog camera
24.2.3
Video Format AVI MPEG2 MPEG2 analog AVI analog
Configuration Constraints
If a catalog specifies unique values for all attributes, then functional requirements can simply be fulfilled by choosing a concrete type for each component. However, additional choices are necessary in the general case in order to configure a component. Firstly, a concrete component type may allow different possible values for technical attributes. Secondly, a component type may not have a fixed function, but permit a choice of alternative functions. In both cases, the attributes of the components may have multiple possible values even if the component type has been chosen. Not all the combinations of those values are legal. Configuration constraints describe which combinations correspond to legal product configurations. There are different kinds of configuration constraints, namely compatibility constraints, requirement constraints and resource constraints. A compatibility constraint specifies which value combinations are legal. It corresponds to a standard constraint in CSPs and has a relation R and a scope. The relation can be specified by a compatibility table which contains the valid value combinations or by an incompatibility table which contains the invalid combinations. These tables can usually be imported from the existing product model of an ERP system. However, the relation can also be specified by a predicate such as equality, inequality, greater-than. The relation is used to restrict the possible values of direct and indirect properties of a component x of a type t. Hence, the scope is an n-ary tuple a1 (x), . . . , an (x) of properties from props(ports∗ (x : t)). If these properties are all single-valued, then the constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∃(v1 , . . . , vn ) ∈ R : (a1 (x) = v1 ∧ . . . ∧ an (x) = vn )
(24.4)
The configuration satisfies ai (x) = vi iff it assigns the value vi to the property ai of x. Compatibility constraints may, in particular, be used to restrict combinations of the types of subcomponents. For example, figure 24.3 shows a compatibility constraint between the storage device type of the edit unit and the video file format of the edited movie. A requirement constraint is also specified by a table and a scope of component properties. However, it expresses a requirement relation between two component properties. A tuple (v1 , v2 ) in the requirement table means that the value v1 of the first property requires the value v2 for the second property. A requirement constraint for type t has a requirement table R and a scope a1 (x), a2 (x) consisting of single-valued properties from props(ports∗ (x : t)). The constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∀(v1 , v2 ) ∈ R : (a1 (x) = v1 ⇒ a2 (x) = v2 )
(24.5)
U. Junker
851
Table 24.4: Requirements for devices. Functional unit Film Unit Manual Edit Unit Computer-based Edit Unit Manual Show Unit Manual Show Unit Computer-based Show Unit
Required Device Camera Video Recorder Computer TV DVD Player Computer
Requirement constraints can be used to restrict combinations of the types of subcomponents. Figure 24.4 shows a requirement constraint between types of the functional units of the home movie studio and the types of its devices. For example, if the functional units include a film unit and a manual show unit, then the devices must include a camera, a TV, and a DVD player. Compatibility constraints can also be applied to multi-valued properties. For example, a computer component may contain a set of peripheries. This set will be subject to multiple compatibility and requirement constraints. However, these constraints are not applied to the components themselves, but to their types. For example, a scanner may require a printer. Two additional difficulties are arising then. Firstly, it is necessary to specify whether the constraint applies to all or to one value as the set of periphery types can contain multiple elements. Secondly, the table entry itself can represent sets of types, namely all the leaf types that specialize the functional or technical type originally listed in the table. The equality tests ai (x) = vi are therefore replaced by intersection tests of the form ai (x) ∩ Vi = ∅. This test is satisfied by a configuration of x if the configuration assigns at least one element of the set Vi to the property ai of the component x. Hence, a compatibility constraint for type t has a compatibility table R and a scope a1 (x), . . . , an (x) over props(ports∗ (x : t)). The constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∃(V1 , . . . Vn ) ∈ R : (a1 (x) ∩ V1 = ∅ ∧ . . . ∧ an (x) ∩ Vn = ∅)
(24.6)
A requirement constraint for type t has a requirement table R and a scope a1 (x), a2 (x) over props(ports∗ (x : t)). The constraint is satisfied by a configuration of a component x of type t if the configuration satisfies ∀(V1 , V2 ) ∈ R : (a1 (x) ∩ V1 = ∅) ⇒ (a2 (x) ∩ V2 = ∅)
(24.7)
Functional properties such as capacities can be seen as a resource that is provided by a system. An example is the storage capacity of a PC that is obtained as the sum of storage capacity of all its disks. The functional requirements usually state that a minimal amount of such a resource should be provided. To meet those requirements, a sufficient number of parts need to be created and configured. Not only can resources be provided by a system, but they can also consumed by it. An example is the total power consumption of a PC, which is the sum of the power consumption of the PC and of its parts. The functional requirements usually state that the consumption of such a resource should not exceed a maximal amount. It is also possible that intermediate components consume resources that
852
24. Configuration
need to be provided by other components. Following [31], resources thus express a balancing task between consumers and producers. Resource constraints [59] ensure that the amount of a produced resource is greater than or equal to the amount of a consumed resource. A resource constraint is applied to all components of a given type t. The consumers and the producers are both represented by subsets of ports∗ (x : t). The produced resource is expressed by a numerical attribute that must be defined for all producers. The consumed resource is expressed by a numerical attribute that must be defined for all consumers. Since both attributes can be different, the root component for the resource constraint can play the role of a producer and consumer. Hence, a resource constraint for a component x of type t is specified by a tuple (P roducers, Consumers, produced, consumed). This constraint is satisfied by a configuration if this configuration satisfies: p(x)∈P roducers
o∈p(x)
produced(o) ≥
consumed(o)
(24.8)
p(x)∈Consumers
o∈p(x)
This model covers also the case where an initial requirement for a minimal amount of a resource (such as storage capacity) needs to be provided by a component. In this case, the producers are the parts of the component (e.g. the storage devices) and the consumer is the component itself, which has a specific consumed-attribute for formulating the requirement (such as required-storage-capacity). Requirements that limit the amount of a consumed resource (e.g. the price) can be formulated as well. In this case, the consumers are the parts of the component and the producer is the component as well, which has a specific produced-attribute corresponding to the maximal amount. It is important to understand that resource constraints express a constraint between the total amount of the resource (i.e. the result of the sum), the bounds of the produced or consumed attributes defined in the catalog, and the number of components. In order to meet minimal cardinalities of ports, new components may be generated during the configuration process. This generation is limited to partonomic ports. Resource constraints can involve other aggregation operators than the sum. Alternatives are min, max, average. Resource constraints can also operate on sets and use a setunion as aggregation operator and the super-set-operator as comparison operator. This is needed to establish a domain for connection-ports. The connection-port (e.g. the storage device of an edit-unit) is a consumed resource that is produced by the actual parts (such as the disks of the computer, the DVD writer of the computer, or the camera). The constraint knowledge for a component x of type t can be summarized as follows: Definition 24.3 (Constraint knowledge). Each type t ∈ Tˆ ∪ T has a set Compat(x : t) of compatibility constraints, a set Requires(x : t) of requirement constraints, and a set Resources(x : t) of resource constraints. These sets are possibly empty. Component types have thus been enriched with three types of constraints, namely compatibility, requirement, and resource constraints. They are formulated on expressions that are defined by the structural model. The compatibility and requirement constraints additionally refer to database-tables that can be imported from existing ERP-systems.
U. Junker
853
24.3 Constraint Models for Configuration A configuration problem is defined by functional requirements and by a configuration model that describes the possible configurations according to the given configuration knowledge. The configuration models in the literature differ quite substantially in the way choices and constraints are represented, although they use the same product models at their origins. It is indeed possible to build different constraint models for the given configuration knowledge. It is even possible to use different constraint models for different component types, meaning that the configuration model is a hybrid one. We first define configuration problems in a general way. In particular, we explain when a configuration model satisfies the given functional requirements. Without loss of generality, it can be assumed that all components that need to be configured are direct or indirect parts of a single root component, which represents the system to be configured. This root component is an instance of a suitable component type, which regroups all the principal components of the system and which contains suitable attributes to describe the functional properties of the system. If such a type does not exist in the given configuration knowledge, then it is straightforward to add such a type description. Given the type t of the system to be configured, we define a functional space for t and a configuration space. The functional space describes the set of complete combinations of functions that can be achieved by an instance of t and the configuration space describes the set of complete configurations for an instance of type t. Such a configuration needs to describe the leaf type t∗ of the instance, the values of each attribute of t∗ (including those inherited from supertypes), the number of elements in each partonomic port of t∗ (including those inherited from supertypes), the configuration of each element of the partonomic port, and the values of each connection port of t∗ (including those inherited from supertypes). Hence, a configuration, in its fully expanded form, is a tree of property-value-pairs. Whereas the function space is finite and obtained as Cartesian product of the domains of the functional attributes of the root component, the configuration space is infinite, but contains finite elements. The function and the configuration spaces usually are not described explicitly, but implicitly by means of a suitable constraint language. Examples for constraint languages are OPL, the CLP(X)-family, or the API’s of constraint libraries. All these languages can be understood as fragments of first-order logic (cf. e.g. [25]) over a fixed structure. They provide a set of predicate symbols, which have a fixed interpretation and which are used to represent the relations of constraints. They also provide a set of function symbols, which have a fixed interpretation and which are used to formulate constrained expressions. Hence, a constraint language can be specified by a first-order language and a structure. For the purpose of configuration, the language is enriched by function symbols representing the ports and properties of components. The interpretation of these additional function symbols can be freely chosen when determining a configuration. A configuration problem for an instance x of type t is then specified by a set of functional requirements F (x : t) and a configuration model K(x : t). The functional requirements are expressed as constraints on the direct functional properties of the root component. The configuration model1 is expressed by constraints on arbitrary properties and 1 The term ‘configuration model’ should not be confused with a logical model of the configuration constraints. The logical model indeed corresponds to a configuration that satisfies those constraints.
854
24. Configuration
ports of the root component, including the functional and technical characteristics. The constraints can contain universal quantifiers, logical connectives, numerical operations, equalities, and comparisons. Compared to Solvers for classical CSPs, a configurator needs to handle these kinds of constraints as well as optional variables, partonomic ports, and variables and constraints with open domains. A configuration problem has a solution iff the union of the functional requirements and the configuration model is satisfiable, i.e. F (x : t) ∪ K(x : t) |= ⊥ [23]. As noted in [28], it is important that the resulting configurations are functionally complete. This means that the configuration S contains sufficient information to decide whether it satisfies an arbitrary requirement or whether it does not satisfy it. S is functionally complete iff either S |= F (x : t) or S |= F (x : t) holds for all requirements F (x : t). Functional completeness is easy to achieve in a constraint-based approach. It is sufficient to include the functional properties in the configuration. Or more formally: functional completeness is straightforward if the function space is obtained as a projection of the configuration space on the functional properties. As the configuration model is expressed in first-order logic, it is not evident whether a configuration problem is decidable. However, configuration problems satisfy the finite model property meaning that the (part) universe of a configuration is finite. The solution can thus be found by an enumeration of the universes. Secondly, the particular partonomic structure and constraint structure used in this chapter allows a complete calculus for proving non-satisfiability of an infeasible configuration problem. The proof can thus be found by enumerating all candidate proofs. The configuration problems considered in this chapter are therefore decidable. In its most general form, a configuration model must be able to describe configurations in its fully extended form where all parts are clearly distinguished and exhaustively described. However, it often is not necessary to distinguish all parts. For example, it may be reasonable to assume that the wheels of a car have the same characteristics. It is then sufficient to represent their number and their product type, which uniquely determines their attribute values. In even simpler problems such as option selection, it is even sufficient to characterize the set of options by a set of types. Hence, the representation of configurations can be simplified and this simplification leads to simpler problems. Simplified configuration problems are also obtained if the given configuration knowledge has a particular form. In the next sections, we introduce several kinds of configuration problems. We distinguish static problems describing a configuration by a fixed set of properties and dynamic problems that involve optional properties or even an unbounded number of properties. Static problems include option selection, shopping lists, or the configuration of systems with a fixed and deterministic structure (car configuration). Dynamic problems include systems with optional parts (computer configuration) and systems with an unbounded number of parts (such as rack configuration or bin packing).
24.3.1
Boolean Models for Option Selection
A very simple configuration problem is obtained if the configured system consists of a set of parts which are entirely characterized by their concrete types. An example is the selection of optional parts for the home movie studio such as a scanner, a printer, an external hard disk. Each option is described by an option type, which has no particular attributes, and each option type can be chosen once only. The options may be organized in a taxonomy
U. Junker
855
and are subject to requirement and compatibility constraints. The functional properties of the system are simply represented by boolean attributes that are linked with the option types via requirement constraints. Definition 24.4 (Option selection problem). The structural model of an option selection problem consists of a type S corresponding to the configured system, a functional type F regrouping all the functions and a functional type O regrouping all the options. The type S has a partonomic port that contains functions from F and a partonomic port that contains the options O. The type F is the root of a function taxonomy and the type O is the root of an option taxonomy, which has concrete types as leaf types. None of the types has attributes. There are requirement constraints between the types of the functions in the function-port and the types of the options in the options-port. There are requirement and compatibility constraints between the types of options in the options-port. The configurations of an option selection problem can be described by a boolean constraint model. This model has the following boolean variables: • A boolean variable fi for each type in the function taxonomy subtypes∗ (F ). This variable has the value 1 iff the configured system has a function of this type. • A boolean variable tj for each type in the option taxonomy subtypes∗ (O). This variable has the value 1 iff the configured system has an option of this type. An entry (f, t) in a requirement constraint between the types of the functions in the functionport and the types of the options in the option ports is represented by an implication: f ⇒t
(24.9)
The direct subtypes t1 , . . . , tn of t in the options or function-taxonomy are modeled by a disjunction: t ≡ t 1 ∨ . . . ∨ tn
(24.10)
A compatibility constraint between the types of the options in the option port can be represented by a set of negative clauses supposing that the constraint has a negative table N which contains the forbidden tuples: ¬t1 ∨ ¬t2
for all (t1 , t2 ) ∈ N
(24.11)
User requirements can be represented by constraints involving the boolean variables f for the function. A boolean problem can be solved by a SAT-solver. Option selection problems are interesting because they can appear as subproblems of more complex problems. This means that the type S is not the root type of a partonomy, but describes the parts of another type. In this case, the boolean variables need to be skolemized since they depend on a component y. The result of the skolemization are terms such as fi (y) and tj (y). An alternative is to use set variables [48] to describe the set of types of all elements in a port. For example, a set variable t(y) could describe all the option types that have been chosen.
856
24. Configuration
24.3.2
Cardinality Models for Shopping Lists
A more complex type of configuration problem is obtained if the functional requirements specify how often a certain functionality should be provided. For example, the home movie studio may require a certain storage capacity for videos and multiple hard disks are needed to provide this capacity. We thus obtain a shopping list and it is necessary to choose the number of instances of a product type. However, the instances need not be distinguished for computing the amount of the consumed and the produced resources as long as these resources have unique values for leaf types. Definition 24.5 (Shopping list problem). The structural model of a shopping list problem consists of a type S corresponding to the configured system (the shopping basket), a functional type F regrouping all the functions, and a functional type I regrouping all the items. The type S has a partonomic port that contains functions from F and a partonomic port that contains the items from I. The type F is the root of a function taxonomy and the type I is the root of an item taxonomy, which has concrete types as leaf types. The types can have attributes, but the values of an attribute a need to be uniquely specified by the leaf types t in the form of a value value(t, a). There are binary requirement constraints between a type of a function in the functions-port and the type of an item in the items-port. There are binary requirement and compatibility constraints between the types of the items in the items-port. Furthermore, there are resource constraints between the function-port and the items-port. The consumed resource is an attribute of F and the produced resource is an attribute of I. The configurations of a shopping-list problem can be described by a cardinality model. This model has the following integer variables: • A positive integer variable #fi for each type in the function taxonomy subtypes∗ (F ). This variable indicates how many times the configured system provides a function of this type. • A positive integer variable #tj for each type in the item taxonomy subtypes∗ (I). This variable indicates the number of items of this type in the configured system. An entry (f, t) in a requirement constraint between the types in the function-port and the types in the items-ports is represented by an implication: (#f ≥ 1) ⇒ (#t ≥ 1)
(24.12)
The direct subtypes t1 , . . . , tn of t in the item taxonomy or the function taxonomy are modeled by a sum. This is possible since two different subtypes have no leaf type in common: #t = #t1 + . . . + #tn
(24.13)
A compatibility constraint between the types of the items in the item-port can be encoded by negative clauses if it is specified by an incompatibility table N : #t1 = 0 ∨ #t2 = 0 for all (t1 , t2 ) ∈ N
(24.14)
U. Junker
857
A resource constraint between a resource c that is consumed by the functions in the function port and a resource p that is produced by the items in the item-port can be modeled by a linear constraint: (24.15) t∈leaves(F ) value(t, c) · #t ≤ t∈leaves(I) value(t, p) · #t User requirements can be represented by constraints involving the integer variables #f for functions. A shopping-list problem can be solved by an Integer Programming approach similar to that in [62]. Shopping list problems can also appear as subproblems of more complex problems. Similar to option selection problems, a single multi-valued variable can be introduced to describe the number of types in a function port or the number of types in an item port. In the case of shopping-lists, the multi-valued variable is a multi-set or bag variable.
24.3.3
CSP-Models for Customizing Flat Components
The configuration model needs to distinguish individual components if the attribute values of the components are not fully determined by the concrete product type. In this case, additional choices are needed to characterize the components and it is necessary to introduce variables for the attributes. For example, the video edit facility requires the customization of several technical components such as the computer, the editing software, the printer, and the scanner. Each of those components has several attributes which are naturally encoded by variables. Those variables are subject to constraints and we obtain a standard constraint satisfaction problem for this flat configuration problem. Definition 24.6 (Flat Customization Problem). The structural model of a flat customization problem consists of a type S corresponding to the configured system, technical types T1 , . . . , Tn representing the principal components. The types need not be all different. The type S has a partonomic port pi that contains exactly one instance of type Ti . The type Ti is a technical type that has concrete types as subtypes. The types S and the types Ti have multiple attributes containing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. There are arbitrary requirement and compatibility constraints between the direct and indirect attributes of the configured system. There are resource constraints between direct attributes of the configured systems and the attributes of the components. The configurations of a flat customization problem can be described by a constraint satisfaction problem. The model has the root component o0 of type S, the components oi which are equal to the ports pi (o0 ), and the following variables: • A variable aj (o0 ) for each attribute aj of the configured system o0 . • A variable aj (oi ) for each attribute aj of the component oi . • A type variable type(oi ) for the type of the component oi . The domain of this variable are the subtypes of Ti . The catalog is translated into an element constraint for each attribute aj and each component oi where i = 1, . . . , n. If subtype t of type Ti restricts the domain of attribute aj to D(t, aj ) then the element constraint is as follows: ∀t ∈ leaves(Ti ) : type(oi ) = t ⇒ aj (oi ) ∈ D(t, aj )
(24.16)
858
24. Configuration
Compatibility constraints can be applied to arbitrary direct and indirect attributes of the configured system, which are represented as variables aj1 (oi1 ), aj2 (oi2 ) where i1 , i2 are in {0, . . . , n}. Hence, the compatibility constraint is expressed as a standard constraint: ∃(v1 , v2 ) ∈ R : (aj1 (oi1 ) = v1 ∧ aj2 (oi2 ) = v2 )
(24.17)
Requirement constraints are expressed similarly in their natural form: ∀(v1 , v2 ) ∈ R : (aj1 (oi1 ) = v1 ⇒ aj2 (oi2 ) = v2 )
(24.18)
Finally, resource constraints can sum up a produced resource aj of multiple components in P ⊆ ports∗ (o0 : S) and a consumed resource aj of multiple components in C ⊆ ports∗ (o0 : S). As the set ports∗ (o0 : S) is equal to the set of components o0 , o1 , . . . , on , the resource constraint is expressed in terms of a numerical constraint: aj (oi ) ≥ aj (oi ) (24.19) oi ∈P
oi ∈C
The functional requirements for flat component properties can be expressed in terms of any functional attribute, whether it is a direct attribute of the configured system or an attribute of one of its components. A flat customization problem can be solved by a constraint solver. If the constraint graph is not dense, appropriate decomposition [13, 26] and clustering techniques can be applied [14] to solve it efficiently.
24.3.4
Conditional CSPs for Taxonomic Reasoning
The same functionality can often be realized by components differing greatly in their technical characteristics. As described in section 24.2.2, technical types fulfilling the same functionality are therefore organized in a taxonomy. Subtypes add further attributes, which means that the set of attributes of a component depend on its precise type. We thus obtain taxonomic customization problems. Formulating this problem as a standard CSP would require including a variable for each possible attribute that can be inherited and ensuring that its value is not meaningful in case it is not inherited. As an alternative, Mittal and Falkenhainer [43] introduced dynamic CSPs with optional variables that are activated under certain conditions. As the term dynamic CSP was later used for CSPs able to support constraint addition and retraction, it was proposed to rename the approach into Conditional CSPs [52]. As observed by Bowen and Bahler [7], it is also possible to directly use first-order logic to model taxonomic customization problems. A further proposal is that of composite CSPs [50], where the variable domains may contain sub-CSPs which are activated when this value is chosen. We model taxonomic customization as a Conditional CSP model, since dedicated algorithms have been elaborated for this approach [52, 24]. Definition 24.7 (Taxonomic Customization Problem). The structural model of a taxonomic customization problem consists of a type S corresponding to the configured system, functional types T1 , . . . , Tn representing the principal components. The types are not necessarily different to each other. The type S has a partonomic port that contains exactly one instance of Ti . The type Ti is the root of a taxonomy, which has concrete types as leaf types. The types S, the types Ti , and the subtypes of the Ti ’s have multiple attributes
U. Junker
859
containing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. A constraint on a type t of the taxonomies can involve any property of type t. There are different possibilities to represent the type variables of the components. It is not only necessary to model that components are instances of concrete product types, but also that they are instances of functional or technical types, such as the technical DVD-type in the following example: if the video edit device is a DVD, then it requires an MPEG2 format. A possibility is to represent type variables as hierarchical variables [38]. An alternative is to use the same representation as for flat problems and to express an instanceof-constraint by a constraint that is satisfied if the value of the type variable is an element of the set of leaves of the type t. This approach has an efficient implementation [40] and is conceptually simpler. For example, the element-constraint representing the catalogs need not be extended to range over functional and technical types. The element-constraint from section 24.3.3 is therefore valid for taxonomic customization problems. Attributes are represented by variables, which can be optional. If type t has an attribute aj and oi is an instance of a supertype of t then the variable aj (oi ) is activated if oi is an instance of t. The activation is denoted by active : aj (oi ), which is a (non-optional!) boolean variable attached to the attribute: type(oi ) ∈ leaves(t) ⇔ active : aj (oi )
(24.20)
The solution of a Conditional CSP just contains the variables for which the active-condition is true. It is convenient to represent such a solution by a set of attribute-value pairs. Compatibility constraints for type t are only activated if the component is an instance of t: (active : aj1 (oi ) ⇒ aj1 (oi ) = v1 ) ∃(v1 , . . . , vk ) ∈ R : ∧ . . . ∧(active : ajk (oi ) ⇒ ajk (oi ) = vk )
(24.21)
Requirement constraints can, however, activate variables: ∀(v1 , v2 ) ∈ R :
(active : aj1 (oi ) ∧ aj1 (oi ) = v1 ) ⇒ (active : aj2 (oi ) ∧ aj2 (oi ) = v2 )
(24.22)
The activation of attributes has also an impact on resource constraints. A resource of type t is provided (or consumed) by a component only if this component is an instance of t. Hence, a resource constraint can only take active resources into account. It may activate produced resources and deactivate consumed resources: aj (o) ≥ aj (o) (24.23) o∈P
active:aj (o)
o∈C
active:aj (o)
Although Conditional CSPs handle the inheritance of attributes, they require that all optional variables and their constraints are created explicitly. The use of universally quantified constraints avoids the creation of optional variables and their constraints if they are not needed. If a component o is an instance of type t, then instances of the constraints of t will be created. For this purpose, the quantified variable of the constraint will be substituted by the component o. It is important to note that a quantified constraint of type
860
24. Configuration
t will only be applied to instances of type t. To achieve this, a set variable instances(t) is introduced to represent the instances of type t. It is linked to the type-variables via an inverse-constraint: ∀i ∈ {0, . . . , n}∀t ∈ subtypes∗ (Ti ) : type(oi ) ∈ leaves(t) ⇔ oi ∈ instances(t) (24.24) The type variable is needed for the catalog constraints, whereas the instance-set variable is used to replace the active-variable. By definition, x ∈ instances(t) is equivalent to active : aj (x) and we can reformulate a compatibility constraint as a universally quantified constraint of type t: ∀x ∈ instances(t) : C(ai1 (x), . . . , aik (x))
(24.25)
If o is an element of instances(t), the forall-constraint adds the variables ai1 (o), . . . , aik (o) and the constraint C(ai1 (o), . . . , aik (o)) to the current CSP. Resource constraints can be adapted by sums that range only over the instances of the types for which the resource is defined.
24.3.5
Conditional CSPs for Simple Partonomic Reasoning
Configurable systems such as computers usually consist of a partonomic hierarchy that has more than two levels. The first level corresponds to the system to be configured and the second level contains the principal components of this system. These principal components may themselves have subcomponents some of which may be optional and some of which depend on the type of the principal component. Furthermore, the subcomponents may be connected to each other. An example is a PC, which has a central unit, which has a processor, which has an optional co-processor. Another example is car configuration with options [43]. We thus obtain a partonomic customization problem which requires the recursive configuration of possibly optional subcomponents and the choice of connections. The problem can again be modeled by a Conditional CSP or by first-order logic. Definition 24.8 (Simple Partonomic Customization Problem). The structural model of a simple partonomic customization problem consists of a type S corresponding to the configured system. S is the root of a partonomy with a taxonomy and a topology such that all partonomic and connection ports contain at most one component. The types in the partonomy can have multiple attributes describing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. A constraint on a type t of the partonomy can involve any property of type t. Special attention needs to be paid naming the properties of subcomponents. Independent of the formalisms, the terms as introduced in section 24.2.2 appear to be the appropriate way. We use the single-valued ports in ports∗ (x : t) and the single-valued properties in props(ports∗ (x : t)) for this purpose. Not only can a component have optional attributes, it can also have optional subcomponents and optional connections, which become active if the component is an instance of the corresponding type. However, there may also be subcomponents and connections that are optional in the sense that the corresponding relation has a minimal cardinality of 0 and a maximal cardinality of 1. If the subcomponent or connected component does not exist, then they are considered inactive as well. If a component is not active then none
U. Junker
861
of its properties and of its ports are active. Therefore, only a subset of ports∗ (x : t) and props(ports∗ (x : t)) are active in a solution. A solution consists of a set of valueassignments to the active properties and to the active connections. The activation of ports can be well addressed by a Conditional CSP or a first-order approach if the properties and ports are modeled as follows: 1. The partonomic ports are treated as variables that are assigned to themselves. 2. The properties of partonomic ports are modeled by variables as before. 3. A connection-port p of a component o of type t is treated as a variable p(o). The domain of p(o) contains the possible instances of the destination type t := type(t, p) from the set of all parts parts∗ (o0 : S) of the root type S. A constraint ensures that the value of p(o) has the type t : ∀o ∈ parts∗ (o0 : S) : p(o) = o ⇒ type(o ) = t
(24.26)
4. The properties and ports ξ(p(o)) of connection-ports are equal to the properties and ports of the component that is assigned to this connection-port. An elementconstraint is needed to express this correspondence: ∀o ∈ parts∗ (o0 : S) : p(o) = o ⇒ ξ(p(o)) = ξ(o )
(24.27)
Hence, single-valued partonomic ports can be handled in a straightforward way. Connection ports, however, are variables that require a special domain management.
24.3.6
Generative CSPs for Complex Partonomic Reasoning
The general case of a configuration problem is obtained when partonomic ports and connection ports can contain an arbitrary number of components. Typical examples occur in equipment configuration where given resource requirements (e.g. on storage capacity) need to be covered by an unknown number of components. Conditional CSPs are no longer appropriate to treat these unbounded configuration problems, since they require the precreation of an infinite number of possible parts. Generative CSPs [60, 59, 17] have been elaborated to handle these complex customization problems. The essence of the generative approach can be described in terms of a first-order formulation. Definition 24.9 (Complex Partonomic Customization Problem). The structural model of a complex partonomic customization problem consists of a type S corresponding to the configured system. S is the root of a partonomy with a taxonomy and a topology. The partonomic and connection ports can contain an arbitrary number of components. The types in the partonomy can have multiple attributes describing functional and technical characteristics. The attributes can have a boolean domain, an enumerated domain, or an interval of integer values. A constraint on a type t of the partonomy can involve any property of type t. The ports of complex partonomic customization are arbitrary elements of ports∗ (x : t) and the properties are arbitrary elements of props(ports∗ (x : t)). Constraints can thus be
862
24. Configuration
formulated on the properties of multi-valued ports. In contrast to an optional port, a multivalued port is active even if it has no element. Hence, there is not need to dynamically activate multi-valued ports. However, it is necessary to dynamically generate new components to meet cardinality constraints on ports. It is sufficient to generate parts for direct ports p(x) ∈ ports(x : t) of a component x. This is achieved by a generative constraint that creates the parts when the lower bound of the cardinality is increased and that adds them to the instance-set of t. This instance-set needs to be represented by a set variable [48] with an open domain [40]: ∀i ∈ {1, 2, 3, . . .} : #p(o) ≥ i ⇒ p(o, i) ∈ instances(t)
(24.28)
If a configuration assigns the value k to the cardinality of a direct partonomic port p of a component x, then the configuration will contain the parts p(x, 1), . . . , p(x, k), but not any other part p(x, k ) with k > k. Since the partonomy is acyclic, each configuration can only contain a finite number of parts. The generative constraint thus generates components on a by-need-basis. It also imposes an important constraint on the port cardinality. If the configuration of the k-th part fails, then it cannot belong to the instance-set meaning that the cardinality of the port is strictly smaller than k. Hence, infinite chains for generating parts are broken as soon as a part cannot be configured. However, infinite ascending chains could be obtained by a search procedure that successively increases the lower bound for the cardinality #p(o) in a search branch. It is nevertheless possible to impose an upper bound on the cardinality based on the following argument. Since components are generated to meet requirement and resource constraints, we determine how many components each such constraint may generate for the port p(o) and use the sum of those upper bounds as an upper bound of the cardinality. We can compute the upper bound for a resource constraint as soon as the total resource consumption has been established. We suppose that the produced resource of each component in the port is greater than a strictly positive lower bound. We can then calculate the upper bound of the number of components by dividing the total amount of the resource by this lower bound. It is important to note that this upper bound on the cardinality imposes an additional constraint on the configuration space. It eliminates configurations with a large number of parts that don’t have any function. Ports of multi-valued partonomic ports can be modeled by recursive constraints. Let ξ be a single-valued port of the destination type of the partonomic port p. The port ξ(p(x)) is then multi-valued. We introduce auxiliary set variables ξ(p(o), i) for the subset that is contributed by the parts p(o, i + 1), p(o, i + 2), . . . , p(o, k), where k is the cardinality: ξ(p(o)) := ξ(p(o), 0) {ξ(p(o, i + 1))} ∪ ξ(p(o), i + 1) if #p(o) ≥ i + 1 ξ(p(o), i) = ∅ otherwise
(24.29)
Multi-valued ports ξ are handled by a similar recursive constraint that directly uses the port ξ(p(o, i + 1)) of the i + 1st component in the union-operation instead of {ξ(p(o, i + 1))}. Properties of partonomic ports are calculated in a similar way except that they are formulated on multi-set (or bag) variables instead of the set variables. If r is a resource of the destination type of a partonomic port, then the resource of the port can be modeled in a recursive way as well. Auxiliary variables r(p(o), i) denote the
U. Junker
863
contribution of the parts p(o, i + 1), p(o, i + 2), . . . , p(o, k), where k is the cardinality: r(p(o)) := r(p(o), 0) r(p(o, i + 1)) + r(p(o), i + 1) if #p(o) ≥ i + 1 r(p(o), i) = ∅ otherwise
(24.30)
A connection port of type t is modeled by an open set variable that is a subset of instances(t). As the elements of connection ports are not ordered, specific union- and sum-over-set-constraints have been introduced in the generative CSP-approaches [40]. The sum-over-set constraint maintains a local consistency among the lower and upper bounds on the port cardinality, the lower and upper bounds on the sum, the set of required elements in the set variable, and the lower and upper bounds of the resources provided by the required elements.
24.3.7
Complex Cases
Complex configuration models can be obtained by combinations of the previously defined models. In particular, components at the leaf level of the partonomy often do not need to be distinguished, thus allowing the use of a boolean or cardinality model. Complex problems are also obtained by more sophisticated representations of the functional properties. Functions can be composed of sub-functions meaning that they are represented by a function partonomy. Functions are then assigned to components and subfunctions need to be assigned to their subcomponents. The sub-functions fulfilled by the subcomponents of a component need to be equal to the sub-functions of the function that is fulfilled by the component. This homomorphism can be expressed by an equality of two union-over-set-constraints. The refinement of function occurs, for example, in the configuration of instrumentation-and-control systems [40] and electrical wiring systems [1]. Complex connection reasoning leads to similar problems if connections between principal components are refined by connections between subcomponents.
24.4 Problem Solving for Configuration Whereas Constraint Programming is used to find a solution or an optimal solution of a CSP, configuration brings in new problem-solving tasks, such as the maintenance of global consistency in interactive configuration, the computation of an explanation if a given set of requirements cannot be satisfied, or the computation of a relaxation of those requirements. The automatic computation of configurations also has particularities. Solution search should produce functionally well-justified configurations instead of an arbitrary configuration. If optimal configurations are required, then the user preferences are rarely specified in terms of a single criterion, but typically involve multiple criteria.
24.4.1
Interactive Configuration
Sales configurators are usually interactive as the functional requirements evolve during the decision-making process. An interactive configurator shows the functional characteristics of the configured system in the form of a web page or a GUI. Each functional attribute is characterized by its possible values. The user can express bounds on these attributes,
864
24. Configuration
eliminate possible values, or choose a value. The configurator typically reacts to those user inputs by propagating their logical effects. If a value is no longer possible for an attribute, then the configurator can eliminate it. Interactive configuration has, for example, been studied in [2] and in the CAWICOMS-project [3]. Definition 24.10 (Interactive configuration task). Given a configuration model K(x : t), user requirement F (x : t), and a set of variables Y representing the functional characteristics, the task consists in finding the set D(y) of legal values for each variable y ∈ Y . A value v is legal for y iff there exists a configuration that satisfies K(x : t) ∪ F (x : t) and that assigns v to y. This task is solved by maintaining global consistency [19] for the functional requirements. A domain D(y) of a variable is globally consistent iff each value v in D(y) is legal for y. An initial domain Dinit (y) taken from the configuration model K(x : t) can be reduced to a maximally global consistent domain D∗ (y) by inspecting each value v of Dinit (y) and by checking whether F (x : t) ∪ K(x : t) ∪ {y = v} is consistent. If this problem is inconsistent, then v will be removed from y’s domain. In the other case, the value v for y is supported by a configuration of F (x : t) ∪ K(x : t). The exhaustive application of a procedure for maintaining global consistency requires n · d consistency checks in the worst case, where n is the number of attributes and d is the initial domain size. If a check has been positive and produced a solution, then this solution will support a value for each functional attribute. Strategies for computing diversified solutions can thus significantly reduce the number of checks. Furthermore, the procedure need not be applied to exhaustion, but may compute a lower bound for D ∗ (y) that contains only supported values and an upper bound that only excludes illegal values. Local consistency methods such as arc consistency [37] can be used to compute the upper bound. In certain cases, when the constraint network is acyclic, then arc consistency coincides with global consistency [20], meaning that the task has a polynomial cost only. For example, this condition is met if only catalog constraints are given. Configuration problems that additionally contain compatibility constraints on variables of the same catalog constraint are not acyclic and arc consistency does not remove all illegal values. Preprocessing techniques can then be used to find all solutions of K(x : t). Cluster techniques limit this preprocessing to the clusters of a cluster-tree [14, 46]. An alternative is to use decision diagrams to store the set of precomputed solutions in a factorized way [2, 29]. However, it is also possible to use suitable strategies for the consistency checks performed by the global consistency procedure. Cutset decomposition [13] and learning of strategies (detection of critical variables [36]) are good candidates for performance increases. Further speed-ups can be obtained by algorithms such as LazyAC [53] or PrefAC [5]. It should also be noted that an interactive configurator solves many configuration problems that share the same configuration model K(x : t) and that differ only in the functional requirements. Preprocessing and learning techniques can therefore pay off significantly.
24.4.2
Explanations and Relaxations
The functional requirement F (x : t) is typically a conjunction of user requirements and can alternatively be represented by a set of requirements, which will be supposed in this sub-section. If F (x : t) ∪ K(x : t) has no solution, then the configuration problem is
U. Junker
865
overconstrained and some requirements need to be relaxed. In this case, the requirements no longer express hard constraints, but desiderata that are satisfied whenever possible. There are two scenarios where such a situation can arise: 1. The user enters one requirement after the other and the interactive configurator reduces the domains of functional attributes after each entry. As the propagation might not eliminate all illegal values, the propagation can reach a dead-end. To recover from the failure, the user needs to find a minimal set of requirements for which propagation is failing, to choose a culprit from this set, and to remove it. This procedure is iterated until the set of the non-relaxed requirements is consistent. 2. The user enters multiple requirements at once, possibly augmented with a preference order. This set of requirements may be inconsistent, meaning that the configurator will compute a relaxation by removing some requirements. Removed requirements are (globally) inconsistent with respect to the selected requirements. The user needs to understand which requirements are causing the failure of a removed requirement. This explanation will allow the user to change the preferences if the removal of a requirement was not acceptable. Hence, overconstrained problems lead to a relaxation and an explanation task. Definition 24.11 (Relaxation task). Given a set of requirements F (x : t), find a maximal relaxation, i.e. a subset that is consistent with respect to the configuration model K(x : t). If additionally a strict partial order on F (x : t) is given, then find a preferred solution in the sense of [8, 33]. It is obtained by choosing a complete ranking of the requirements and by doing a lexicographic maximization based on this ranking. Definition 24.12 (Explanation task). Given an overconstrained set of requirements F (x : t), find a minimal conflict, i.e. subset that is inconsistent with respect to the configuration model K(x : t). If additionally a strict partial order on F (x : t) is given, then find a preferred conflict in the sense of [33]. It is obtained by choosing a complete ranking of the requirements and by doing an anti-lexicographic minimization based on this ranking. Relaxations are usually computed by adding one requirement after the other in the chosen order and by testing the consistency of the current selection after each step. If a solution has been found, then the requirement is kept. Otherwise, it is removed. Conflicts have traditionally been computed by truth maintenance system (TMS) [15] and several attempts have been made to integrate a TMS into a constraint solver [35, 57]. However, the computed explanations can be far from minimal, in particular if resource constraints are involved (see [33] for an example). A method for computing minimal and preferred conflicts is presented in [33]. The algorithm called QuickXplain solves the explanation problem by successively removing requirements and by checking the consistency of the remaining requirements. If the remaining requirements are inconsistent, the problem has been reduced in size. If not, then some of the removed requirements do necessarily belong to the conflict. QuickXplain is recursively dividing the explanation problem into subproblems of the same size. For example, the initial set F (x : t) will be split into two subsets C1 and C2 . It first seeks for conflict elements in C2 while keeping C1 in the background (i.e, all constraints of C1 are active, but they will not be removed while solving the second problem). The first step then
866
24. Configuration
consists in removing all elements of C2 and testing the consistency of K(x : t)∪C1 . If this fails, the empty set is a minimal conflict of the second problem, meaning that the problem has been reduced to C1 . If the test succeeds, then at least one requirement in the second problem is needed for the failure. If the second problem is a singleton, then its element is added to the conflict. If the second problem has multiple elements, it is again split into two parts and the procedure is applied recursively. When the second subproblem has been successfully solved, its minimal conflict is added to the background and the first subproblem is removed from the background. Then the first subproblem is solved. A minimal conflict for the complete problem is then obtained by merging the minimal conflicts of the first and second subproblems. Evolutions of QuickXplain have been proposed to explain the values chosen in a solution [22] and to find the parts of an overconstrained problem that need to be repaired when restoring the consistency [45].
24.4.3
Searching Solutions
Whereas interactive configurators mainly support propagation and explanation, the automatic search of solutions if an important features of configurators in manufacturing. We discuss the search of solutions for the most general form of configuration problem, which corresponds to a generative CSP. A search procedure for a generative CSP does not only need to choose a value for the different variables of the initial problem. It also needs to take into account variables that are added by inheritance or by the generation of subcomponents. These variables are added when the search procedure is making decisions about a component type or about the cardinality of a partonomic port. It is important to note that decisions about newly generated variables cannot precede the decisions that lead to their generation. As a consequence, the sequence of search decisions that produces a solution needs to respect this order. By doing this, the search configures a component by top-down refinement. The dynamic nature of complex configuration problems also contradicts some basic postulates of constraint programming that state that it is better to eliminate inconsistent choices a priori by a propagation procedure than doing this a posteriori by analyzing and learning a conflict. Configurators need to make wrong decisions in order to discover that they are wrong. For example, it is possible that a given computer type t is incompatible with respect to the given requirements. However, it may be necessary to generate all the variables and constraints that are inherited from this type in order to discover the incompatibility. This is only possible if the computer has been specialized to the type t. The conflict between the type assignment and the functional requirements that is discovered in this way provides useful information for the ongoing configuration process. Therefore, it is recommended to keep those conflicts [47]. Another issue is obtained by search decisions that choose the number of parts or that choose the functionality of the part. The search should avoid under-charged components and over-fulfilled functions. An example of under-charged components is obtained if two servers are provided for 10 users, although a single one is sufficient. Over-fulfilled functions are obtained if there is a single demand for a printing capability, but two printers are provided. Whereas over-fulfilled functions can be avoided by a suitable constraint model, under-charged components cannot be avoided by constraints. If the search procedure chooses the number of components before configuring them, it can easily end up with
U. Junker
867
under-charged components. Furthermore, it can produce under-charged components if it chooses more components than necessary or if it chooses less functionality than possible. These problems can be avoided if configurations are produced by decision sequences that respect certain properties. When a component is configured, then the following kinds of decisions should be taken in the following order: 1. First, the values for the functional attributes of the root type of the component are chosen. The functions of the component can be maximized by applying the following preferences. The presence of a capability is preferred to its absence, meaning that the value true is preferred to the value false for boolean attributes. For numerical capacities, higher values are preferred. The search procedure should then assign the best value to each functional attribute. However, trade-off considerations between multiple functional attributes allow the procedure to abandon a best value for an attribute a1 (o) if this allows an improvement for a later attribute a2 (o). The procedure can avoid a high penalization of a2 (o) by auxiliary decisions a2 (o) ≥ v that are made before assigning a value to a1 (o). As shown in [32], any Pareto-optimal combination of the attribute values can be found in this way. 2. Once the functional characteristics are chosen, the type variable is specialized by decisions of the form type ∈ leaves(t). Multiple specialization decisions can occur for the same type variable. Inherited properties and ports can be configured as soon as they are generated by such a decision. There is no predefined order among the inherited properties and ports, meaning that technical attributes, cardinalities, and connections can be configured in any order if not otherwise specified. 3. The values of the technical attributes are chosen by standard value assignments. There are no predefined preferences between these values. 4. The cardinalities of partonomic ports are chosen by decisions of the form #p(o) ≤ k and smaller values for the bound k are preferred. If such a decision fails, then its negation #p(o) > k is added to the constraints. This generates a new subcomponent p(o, k + 1) that needs to be configured before the next cardinality decision #p(o) ≤ k + 1 is tried out. The component p(o, k + 1) is configured by applying the whole configuration process recursively. 5. Connection ports are configured by membership decisions of the form o ∈ p(o). There are no predefined preferences. The task for searching a functionally well-justified solution can be expressed as follows: Definition 24.13 (Solution search task). Find a configuration that satisfies the given functional requirements and the given configuration model by a sequence of search decisions that have the form discussed above and that respect the preferences between values and variables as discussed above. Preference programming [34] proposes a language for expressing decisions and preferences for configuration problems. In addition to the structural preferences, specific preferences among the attributes of a component can be expressed as well. Whereas preference programming defines a strategy for producing a solution, other strategies may be needed to recover from a failure. Blind strategies such as min-domain-first ignore the specific
868
24. Configuration
structure of a configuration problem and do not appear to be well-adapted for this case. Strategies that move up the failure [36], cutset decomposition [13], or dependency-directed backtracking [15] are better candidates. Learning methods may also be a good way in order to identify critical variables for proving the infeasibility of a subproblem. Difficult configuration problems can also profit from symmetry-breaking methods [21]. However, the most important issue is to avoid the introduction of symmetries by the configuration model. The partonomic model presented in section 24.2.2 avoids symmetries between parts. The elements of a partonomic port are ordered and the individual elements cannot be referenced inside constraints. They are indistinguishable before being configured. A sequence of search decisions that is inconsistent for one part, will also be inconsistent for the next part. Hence, the configuration of the k + 1-st part can start where the configuration of the k-th part has stopped.
24.4.4
Satisfying User Preferences
An advanced issue in configuration is the satisfaction of user preferences. As the layman user does not know the configuration model, she or he will often run into underconstrained or overconstrained situations when specifying the requirements through the form of constraints. Underconstrained situations leave a large set of choices and there is a high risk that users miss their favorite choice. Overconstrained situations are obtained if the users choose their preferred value for each attribute. In the first case, users will not feel very confident about the obtained configuration since they have not explored the limits. In the second case, the users need to toggle through an inconsistent set of requirements and manage the preferences on their own. The need for preference handling for configuration problems has for example been expressed in [28]. Preference-based configurators offer a simple way to specify preferences in an intuitive and qualitative way. CP-nets are a successful formalism for ordering the values of an attribute dependent on the values of parent attributes [6]. Symbolic preference programming permits the user to order the requirements and to specify an order for numerical or qualitative attributes [34]. Given such preferences on multiple attributes (also called criteria), a multi-criteria optimization problem has to be solved. Although any Pareto-optimal solution of this problem may be interesting, it is often more appropriate to guide the user through the set of possible compromises by generating multiple extreme solutions (lexicographicoptimal for different rankings) and balanced solutions [32]. This approach thus generates a small set of preferred solutions of a good diversity. Diversity is ensured by changing the importance of criteria. Diversity can also be enforced by global constraints [30]. Future work on preference-based configurators is needed to develop the full potential of this feature. This includes work on algorithms, on the preference language, and on the preference elicitation methods. Explanations of failure provide a good opportunity to ask for preferences between the possible relaxations. Hence, explanations can play a key role in making preference elicitation more interactive and more efficient.
24.5 Conclusion This chapter has given an overview on constraint-based configuration while stressing the particularities of configuration. Configuration is not a classical application of Constraint
U. Junker
869
Programming. The constraint networks are not static, but evolve during problem solving. As such, the formalism of constraint networks is not sufficient to specify a configuration problem and it is necessary to go up to a higher modeling level, which describes the configuration knowledge independent of a problem-solving formalism. Configuration knowledge covers product data as found in the databases of an ERP system, structural models that can be formulated within UML or within a description logic, and the configuration constraints. The structural model includes a description of the functional characteristics and of the alternative ways to map them to a structure. Depending on the characteristics of the configured system, this knowledge can be compiled into various kinds of constraint models including boolean models, cardinality models, static and dynamic CSP models, and generative CSP models. The latter ones support dynamic activation or generation of variables and constraints and thus create new issues for the search process. The search process has to take dynamically generated variables into account and needs to respect the generation order. The search process is function-driven and should make choices only when they contribute to given functional requirements. Searching for solutions is not the only problem-solving task that occurs in configuration. Interactive configurators often support a form of (strong) propagation and let the user make the decisions. The user thus has the freedom to try out all of her or his preferred choices with the risk of running into overconstrained problems. Explanation facilities then allow the user to identify conflicting requirements, but still leave them the burden of choice. An alternative is the emerging idea of a preference-based configurator where users enter preferences among the possible values instead of making categoric choices. Preferences are heavily used in recommender systems and the lessons learned in this area may be beneficial for configuration. However, interactive configurators and their explanation facilities can also lead to new possibilities for preference elicitation, meaning that there is a potential for a cross-fertilization between both fields.
Bibliography [1]
Michel Aldanondo, Jacques Lamothe, and Khaled Hadj Hamou. Configurator and CAD: gathering the best of two worlds. In IJCAI-01 Workshop on Configuration, pages 1–14, 2001. [2] J´erˆome Amilhastre, H´el`ene Fargier, and Pierre Marquis. Consistency restoration and explanations in dynamic CSPs application to configuration. Artificial Intelligence, 135(1-2):199–234, 2002. [3] Liliana Ardissono, Alexander Felfernig, Gerhard Friedrich, Anna Goy, Dietmar Jannach, Giovanna Petrone, Ralph Sch¨afer, and Markus Zanker. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine, 24(3):93–110, 2003. [4] Virginia E. Barker, Dennis E. O’Connor, Judith Bachant, and Elliot Soloway. Expert systems for configuration at Digital: XCON and beyond. Commununications of the ACM, 32(3):298–318, 1989. [5] Christian Bessi`ere, Ana¨ıs. Fabre, and Ulrich Junker. Propagate the right thing: how preferences can speed-up constraint solving. In Eighteenth International Joint Conference on Artificial Intelligence, pages 191–196, Acapulco, 2003. [6] Craig Boutilier, Ronen I. Brafman, Carmel Domshlak, Holger H. Hoos, and David
870
[7]
[8]
[9]
[10]
[11]
[12] [13] [14] [15] [16]
[17]
[18]
[19] [20] [21]
[22] [23] [24]
24. Configuration Poole. Preference-based constrained optimization with CP-nets. Computational Intelligence, 20:137–157, 2004. James Bowen and Dennis Bahler. Conditional existence of variables in generalised constraint networks. In Ninth National Conference on Artificial Intelligence (AAAI), pages 215–220, 1991. Gerhard Brewka. Preferred subtheories: An extended logical framework for default reasoning. In Eleventh International Joint Conference on Artificial Intelligence, pages 1043–1048, 1989. David C. Brown and B. Chandrasekaran. Design problem solving: knowledge structures and control strategies. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1989. Roman Cunis, Andreas G¨unter, Ingo Syska, Heino Peters, and Heiner Bode. Plakon - an approach to domain-independent construction. In Second International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems (IAE/AIE), pages 866–874, 1989. Adnan Darwiche. New advances in compiling CNF into decomposable negation normal form. In Sixteenth European Conference on Artificial Intelligence, pages 328– 332, 2004. Johan de Kleer. An assumption–based truth maintenance system. Artificial Intelligence, 28:127–162, 1986. Rina Dechter. Enhancement schemes for constraint processing: Backjumping, learning, and cutset decomposition. Artificial Intelligence, 41(3):273–312, 1990. Rina Dechter and Judea Pearl. Tree clustering for constraint networks. Artificial Intelligence, 38:353–366, 1989. Jon Doyle. A truth maintenance system. Artificial Intelligence, 12:231–272, 1979. Alexander Felfernig, Gerhard Friedrich, and Dietmar Jannach. UML as domain specific language for the construction of knowledge-based configurations systems. International Journal of Software Engineering and Knowledge Engineering, 10(4):449 – 469, 2000. Gerhard Fleischanderl, Gerhard Friedrich, Alois Haselb¨ock, Herwig Schreiner, and Markus Stumptner. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems, 13(4):59–68, 1998. Felix Frayman and Sanjay Mittal. COSSACK: A constraint-based expert system for configuration. In Knowledge-Based Expert Systems in Engineering: Planning and Design, pages 143–166. Computational Mechanics Publications, 1987. Eugene C. Freuder. Synthesizing constraint expressions. Communications of the ACM, 21(11):958–966, 1978. Eugene C. Freuder. A sufficient condition for backtrack-free search. Journal of the ACM, 29(1):24–32, 1982. Eugene C. Freuder. Eliminating interchangeable values in constraint satisfaction problems. In Proceedings of the Ninth National Conference on Artificial Intelligence (AAAI), pages 227–233, 1991. Gerhard Friedrich. Elimination of spurious explanations. In Sixteenth European Conference on Artificial Intelligence, pages 813–817, 2004. Gerhard Friedrich and Markus Stumptner. Consistency-based configuration. In AAAI99 Workshop on Configuration, pages 35–40, 1999. Felix Geller and Michael Veksler. Assumption-based pruning in conditional CSP.
U. Junker
[25] [26] [27]
[28] [29]
[30]
[31] [32] [33]
[34]
[35]
[36] [37] [38]
[39]
[40]
[41]
871
In Eleventh International Conference on Principles and Practice of Constraint Programming, pages 241–255, 2005. Michael R. Genesereth and Nils J. Nilsson. Logical Foundations of Artificial Intelligence. Morgan Kaufmann, Palo Alto, CA, 1987. Georg Gottlob, Nicola Leone, and Francesco Scarcello. A comparison of structural CSP decomposition methods. Artificial Intelligence, 124(2):243–282, 2000. Andreas G¨unter and Christian K¨uhn. Knowledge-based configuration: Survey and future directions. In 5th Biannual German Conference on Knowledge-Based Systems, volume 1570 of Lecture Notes in Computer Science, pages 47–66, 1999. Albert Haag. Sales configuration in business processes. IEEE Intelligent Systems, 13(4):78–85, 1998. Tarik Hadzic, Sathiamoorthy Subbarayan, Rune M. Jensen, Henrik R. Andersen, Jesper Moller, and Henrik Hulgaard. Fast backtrack-free product configuration using a precompiled solution space representation. In International Conference on Economic, Technical and Organisational aspects of Product Configuration Systems, pages 131–138, 2004. Emmanuel Hebrard, Brahim Hnich, Barry O’Sullivan, and Toby Walsh. Finding diverse and similar solutions in constraint programming. In The Twentieth National Conference on Artificial Intelligence (AAAI), pages 372–377, 2005. Werner E. Juengst and Michael Heinrich. Using resource balancing to configure modular systems. IEEE Intelligent Systems, 13(4):50–58, 1998. Ulrich Junker. Preference-based search and multi-criteria optimization. Annals of Operations Research, 130:75–115, 2004. Ulrich Junker. QUICKXPLAIN: preferred explanations and relaxations for overconstrained problems. In Nineteenth National Conference on Artificial Intelligence (AAAI), pages 167–172, 2004. Ulrich Junker and Daniel Mailharro. Preference programming: Advanced problem solving for configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 17(1):13–29, 2003. Narendra Jussien, Romuald Debruyne, and Patrice Boizumault. Maintaining arcconsistency within dynamic backtracking. In Sixth International Conference on Principles and Practice of Constraint Programming, pages 249–261, 2000. Olivier Lhomme. Quick shaving. In Twentieth National Conference on Artificial Intelligence (AAAI), pages 411–415, 2005. Alan K. Mackworth. Consistency in networks of relations. Artificial Intelligence, 8(1):99–118, 1977. Alan K. Mackworth, Jan A. Mulder, and William S. Havens. Hierarchical arc consistency: exploiting structured domains in constraint satisfaction problems. Computational Intelligence, 1:118–126, 1985. Diego Magro and Pietro Torasso. Decomposition strategies for configuration problems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 17(1):51–73, 2003. Daniel Mailharro. A classification and constraint based framework for configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4):383–397, 1998. John P. McDermott. R1: A rule-based configurer of computer systems. Artificial Intelligence, 19:39–88, 1982.
872
24. Configuration
[42] Deborah L. McGuinness and Jon R. Wright. Conceptual modelling for configuration: A description logic-based approach. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4):333–344, 1998. [43] Sanjay Mittal and Brian Falkenhainer. Dynamic constraint satisfaction problems. In Eighth National Conference on Artificial Intelligence (AAAI), pages 25–32, 1990. [44] Sanjay Mittal and Felix Frayman. Towards a generic model of configuration tasks. In Eleventh International Joint Conference on Artificial Intelligence, pages 1395–1401, 1989. [45] Barry O’Callaghan, Barry O’Sullivan, and Eugene C. Freuder. Generating corrective explanations for interactive constraint satisfaction. In Eleventh International Conference on Principles and Practice of Constraint Programming, pages 445–459, 2005. [46] Bernard Pargamin. Extending cluster tree compilation with non-boolean variables in product configuration: A tractable approach to preference-based configuration. In IJCAI-03 Workshop on Configuration, pages 32–37, Acapulco, Mexico, 2003. [47] Charles J. Petrie. Constrained decision revision. In Tenth National Conference on Artificial Intelligence (AAAI), pages 393–400, 1992. [48] Jean-Franc¸ois Puget. PECOS: a high level constraint programming language. In Proceedings of the 1st Singapore International Conference on Intelligent Systems (SPICIS’92), pages 137–142, Singapore, 1992. [49] Raymond Reiter. A theory of diagnosis from first principles. Artificial Intelligence, 32:57–952, 1987. [50] Daniel Sabin and Eugene C. Freuder. Configuration as composite constraint satisfaction. In George F. Luger, editor, Proceedings of the Artificial Intelligence and Manufacturing Research Planning Workshop, pages 153–161. AAAI Press, 1996, 1996. [51] Daniel Sabin and Rainer Weigel. Product configuration frameworks - a survey. IEEE Intelligent Systems, 13(4):42–49, 1998. [52] Mihaela Sabin, Eugene C. Freuder, and Richard J. Wallace. Greater efficiency for conditional constraint satisfaction. In Ninth International Conference on Principles and Practice of Constraint Programming, pages 649–663, 2003. [53] Thomas Schiex, Jean-Charles R´egin, Christine Gaspin, and G´erard Verfaillie. Lazy arc consistency. In Thirteenth National Conference on Artificial Intelligence (AAAI), pages 216–221, 1996. [54] Patrik Simons, Ilkka Niemel¨a, and Timo Soininen. Extending and implementing the stable model semantics. Artificial Intelligence, 138(1-2):181–234, 2002. [55] Carsten Sinz, Andreas Kaiser, and Wolfgang K¨uchlin. Formal methods for the validation of automotive product configuration data. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 17(1):75–97, 2003. [56] Timo Soininen, Esther Gelle, and Ilkka Niemel¨a. A fixpoint definition of dynamic constraint satisfaction. In Fifth International Conference on Principles and Practice of Constraint Programming, pages 419–433, 1999. [57] Mohammed H. Sqalli and Eugene C. Freuder. Inference-based constraint satisfaction supports explanation. In Thirteenth National Conference on Artificial Intelligence (AAAI), pages 318–325, 1996. [58] Markus Stumptner. An overview of knowledge-based configuration. AI Communications, 10(2):111–125, 1997. [59] Markus Stumptner, Gerhard Friedrich, and Alois Haselb¨ock. Generative constraint-
U. Junker
[60]
[61]
[62]
[63] [64]
[65]
873
based configuration of large technical systems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 12(4):307–320, 1998. Markus Stumptner and Alois Haselb¨ock. A generative constraint formalism for configuration problems. In Advances in Artificial Intelligence, Third Congress of the Italian Association for Artificial Intelligence, AI*IA’93, pages 302–313, 1993. Gruber T., Olsen G.R, and Runkel J.T. The configuration design ontologies and the VT elevator domain theory. International Journal of Human-Computer Studies, 44(4):569–598, 1996. Erlendur S. Thorsteinsson and Greger Ottosson. Linear relaxations and reduced-cost based propagation of continuous variable subscripts. Annals of Operations Research, 115:15–29, 2002. Rainer Weigel and Boi Faltings. Compiling constraint satisfaction problems. Artificial Intelligence, 115(2):257–287, 1999. Brian C. Williams. Interaction-based invention: Designing novel devices from first principles. In Proceedings of the Eighth National Conference on Artificial Intelligence (AAAI), pages 349–356, 1990. Katariina Ylinen, Tomi M¨annist¨o, and Timo Soininen. Configuring software products with traditional methods - case LINUX family. In ECAI-02 Workshop on Configuration, pages 17–22, 2002.