Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part V. Configuration Environments

Chapter 26. VariSales

Juha Tiihonen^a and Andreas Anderson^b, ^aAalto University, Aalto, Finland, ^bVariantum, Espoo, Finland

Abstract

In this chapter we outline the modeling of the PC configuration knowledge base with VariSales. VariSales is based on object-oriented knowledge representations with a clear underlying semantics. The VariSales environment consists of a semivisual Modeling Tool and a web-based Configuration Tool. It applies an inference engine that follows the logic-based Answer Set Programming (ASP) paradigm.

Keywords

Knowledge-based Configuration; Sales Configurator; Graphical Modeling; Weight Constraint Rule Language; User interface Generation

Acknowledgments

This work has been supported by Technology Development Centre of Finland and Aalto Service Factory. Basics of VariSales were described in this chapter on the basis of Tiihonen et al. (2013).

26.1 Introduction

Many problem solving methods provide an explicit or implicit conceptual model for representing configuration models, requirements, and configurations, in other words configuration knowledge. In our view, a practical approach in terms of configurator maintainability is to provide a configuration-specific modeling conceptualization that can be applied to express configuration knowledge. The task of the configuration system is to map this knowledge into a form that can provide the inference required to support the configuration task.

We believe that the configuration ontology introduced by Soininen et al. (1998) covers a broad range of configuration problems. However, in many companies that we visited during several research projects, order forms for sales configuration were relatively simple, typically a page or two in A4 format. The configuration task was straightforward, requiring only limited inference. VariSales, which is the commercialized version of WeCoTin (Tiihonen et al., 2003, 2013), was developed mainly to address these simpler problems.

The remainder of this chapter is organized as follows. Section 26.2 gives an overview of the modeling concepts of VariSales and shows how taxonomic hierarchies, attributes, compositional structures, and constraints are defined (represented). Section 26.3exemplifies the modeling of resource constraints and Section 26.4 introduces user interface modeling and the resulting VariSales interface for end-users. Finally, a brief discussion and conclusions are provided.

26.2 Modeling of the Working Example

A significantly reduced subset of the configuration ontology introduced by Soininen et al. (1998) provides a conceptual basis for the modeling language of VariSales. This subset is represented by the Product Configuration Modeling Language (PCML). PCML was implemented under the belief that it can support a practical and relevant set of sales configuration tasks. It includes taxonomy, compositional structure, attributes, and constraints. Connection-oriented concepts (ports) and even resources were left out. The main concepts of PCML are feature types, their compositional structure, attributes, and constraints. Feature types define the subfeatures (parts) and attributes of their individuals that can appear in a configuration. An overview of the PC configuration model introduced in Hotz et al. (2014)¹ is shown in Figure 26.1.

FIGURE 26.1 Example PC in VariSales Modeling Tool.

Semantics of PCML are provided by mapping PCML to Weight Constraint Rule Language (WCRL), applying the idea of Soininen et al. (2001). The Smodels system provides an efficient inference engine for WCRL (Simons et al., 2002). Development of WCRL andSmodels took into account configuration as a potential application domain.

26.2.1 Taxonomic Hierarchy and Attributes

The VariSales Modeling Tool provides editing of feature types, their class hierarchy, and attributes. This includes creating, removing, renaming (maintaining model consistency), and changing subclass hierarchies. The Feature type tree displays the class hierarchy (see the upper left-hand corner of Figure 26.1) and serves as a starting point for editing all aspects of the types. Editing the selected object takes place in the right side of the display or sometimes in pop-up windows. In the Feature type tree, colored squares differentiate between concrete (blue), abstract (red) types, and the configuration type (green). The tree shows the complete taxonomic hierarchy of the example. Some of these and attribute definitions of PC are shown in textual PCML format here:

feature PC

attribute usage

value type string constrained by $

in list("internet","scientific","multimedia")

attribute efficiency

value type efficiency_valueType constrained by $

in list("A","B","C")

no default

constraint crc1

( ( usage = "internet" ) or ( usage = "multimedia" ) )

implies present (InternetConn)

feature PC_Component

abstract

feature InternetConn

subtype of PC_Component

The feature type overview (right-hand side of Figure 26.1) allows adding or removing attributes, and changing the abstraction level or the name of the currently selected type. The tab Attributes shows an overview of the attributes of the selected feature type PC. Attribute efficiency was defined through a new value type—the same definition is needed in several places, and available efficiency classes are prone to change. The value type was defined via the graphical user interface, in textual PCML form it is:efficiency_valueType string constrained by $ in list("A", "B", "C").

26.2.2 Compositional Structure

A feature type defines its compositional structure through a set of subfeature definitions. A subfeature definition specifies a subfeature name, a nonempty set of possible subfeature types (allowed types for brevity), and a cardinality indicating the valid number of subfeatures.

In a configuration, subfeatures (parts) of a feature individual are realized with feature individuals. The realizing feature individual(s) “fill the role” created by the effective subfeature definition. An explicit empty realization is possible, when cardinality 0 is allowed. An “optional part” common in industrial products is modeled as a subfeature that allows an empty realization. A default realization can include attribute values and subfeature realizations of arbitrary depth. In addition, an empty realization (special valuenone) can be set as the default realization. Inherited subfeatures can be refined by restricting allowed types, cardinality, or by modifying or hiding default subfeature realizations.

The compositional structure is shown in the subfeature hierarchy tree (lower left-hand side of Figures 26.1 and 26.2). Drag & Drop from the feature type tree enables adding allowed feature types, subfeature definitions, and defaults.

FIGURE 26.2 Compositional structure of HDUnit in VariSales Modeling Tool.

The right-hand side of Figure 26.2 shows an overview of subfeatures of the feature type HDUnit. Each HDUnit has as part named HD_Controllers 1 to 2 individuals of any subtype of HDController, and as Hard_disks 1 to 4 individuals of any subtype of HDisk. No defaults are set for the subfeatures.

In the textual PCML presentation the corresponding part of the configuration model is expressed as follows:

feature HDUnit

subtype of PC_Component

subfeature Hard_disks

allowed features HDisk

cardinality 1 to 4

subfeature HD_Controllers

allowed features HDController

cardinality 1 to 2

26.2.3 Constraints

A feature type can define constraints. In this example, we only apply hard constraints that define conditions that a correct configuration must satisfy. A configuration is considered consistent if and only if no hard constraint in any feature individual is violated. If any hard constraint is broken, the purchase process cannot be completed, for example, placing the configuration in the shopping cart is prevented.

Constraints are expressed in a constraint language and named uniquely within a feature type. The first-level building blocks of the constraint language are references to access subfeatures, attributes of features, and constants such as integers or strings. References can be used in succession, for example, to access an attribute of an individual realizing a subfeature. Tests returning Boolean values are constructed using references, constants, and arithmetic expressions. Tests include predicates for checking if a particular referenced individual exists or is of a given type. Attribute references can be used with constants in arithmetic expressions. These can be compared with the usual relational operators to create a test. Tests can be further combined into arbitrarily complex Boolean expressions using the standard Boolean connectives.

The VariSales Modeling Tool provides several ways to define constraints: textually, graphically, and as table constraints. Tab Constraints (Figure 26.1) in Feature type overview lists the constraints of the active feature type in textual form and facilitates adding new constraints.

Many constraints are relatively simple, often in the form of requires- and incompatible- relationships. To make entering and modifying simple constraints easier, VariSales Modeling Tool has a graphical constraint editor. It is possible to use the and and orconnectives to create subexpressions. These subexpressions can be used, for example, as requiring, required, or incompatible factors in more complex graphical expressions.

Figure 26.3 illustrates the constraint crc1 (see Table 26.1 and Section 26.2.1 for textual PCML representations), created with the graphical constraint editor. First, the constraint was named, and the requires symbol was brought to the canvas. Arguments and subexpressions were brought to place with Drag & Drop support. This freed the modeler from tedious and error-prone typing of object names and values.

FIGURE 26.3 Constraint CRC1 as a graphical constraint in VariSales Modeling Tool.

Table 26.1

Implementation of constraints specified in Hotz et al. (2014) (Chapter 6).

Table 26.1 exemplifies the implementation of constraints of our example PC configuration knowledge base (see Hotz et al., 2014²).

26.3 Price and Hard Disk Capacity

VariSales has two mechanisms for determining prices. The basic pricing mechanism applies simple additive prices while the advanced calculation mechanism enables freely specifiable calculations. The price of the example PC is determined with the basic mechanism, and the advanced calculation mechanism is applied to calculate hard disk resource production and consumption.

The basic pricing mechanism is simple: each feature individual has the price specified by its type; the default is no price (0). In addition, each attribute value can be given a price. Prices of feature individuals and prices of attribute values in a configuration are summed in the web browser after each selection. The user interface displays prices in the context of selecting a realizing feature type or an attribute value. For example, the Screen price is determined with prices of individual attribute values of efficiency. Other prices such as those of CPUs are determined only on the basis of the type. A part of the PC price list (in XML format) is:

<configurationPriceList currency="euro" model="ElsevierPC"

name="euro" pricesIncludeTax="true" tax="0.23">

</attribute>

</feature>

</feature>

The advanced calculation mechanism can perform calculations as a function of the current configuration, configuration model, and data in specific databases or XML files. The mechanism processes calculation items, each equipped with a condition expression examining the configuration and a set of assignments. Here, the mechanism is applied to determine TotalHDCapacity, TotalHDUse, and FreeHDCapacity to be shown to the user. In upper left of Figure 26.4, OSBeta has taken 13 GB and 20 Application each 20 GB, totaling 413 GB of use. Two MaxStoreDisks provide a total of 2000 GB, leaving 1587 GB of free capacity.

FIGURE 26.4 Configuration Tool user interface of the example.

26.4 User Interface Modeling and Generation

26.4.1 Layouts

A web-based user interface for the end user is generated without programming. The user makes selections on an HTML form; for example, see the right side of Figure 26.4. The general idea is that each selectable attribute or subfeature of a feature individual being configured generates a question. The modeler creates a layout to define how questions related to a feature individual are divided into pages, the order of questions, and, optionally, the type of input control used for a question.

For example, PC is divided into Requirements (usage, efficiency), software (Operating_System, Applications, storage (for HDUnits), hardware (Motherboard, Screens), and Internet (InternetConn). These groups are reflected in the configuration tree on the left-hand side ofFigure 26.4.

26.4.2 Resources

In principle, the language of a configuration model is independent of the language(s) of the end-user interface. A resource file defines display names of objects of the configuration model to be shown to end users and their optional descriptions. In addition, resources define links to web pages providing additional information, messages for broken constraints, and so on. Multiple resources support multiple languages for end users.

Here, few resources were defined, so the names visible to the user come directly from those used in the configuration model (underscores in identifiers were automatically replaced with spaces). For the sake of demonstration, MedStoreDisk was renamed with resources and a descriptive text added to both hard disk types. See the right-hand side of Figure 26.4.

Because the configuration model was created with suitable terminology, near-automatic user interface generation in the primary language was possible.

26.4.3 Other User Interface Aspects

The general appearance of the user interface is defined by web-page templates. Defaults were used, except that hard-disk calculation results were added to the status area (upper left-hand side of Figure 26.4). This separates definition of visual appearance from the product-dependent parts of the user interface.

26.5 Conclusion

This chapter showed how to model the example PC with VariSales. Taxonomic hierarchy and attributes with refinement, compositional structure, and constraints were applied in a straightforward manner. All aspects were not modeled: Topological (connection) constraints were not modeled because VariSales currently does not support them, and they provide no additional value in the example. Resource constraints were managed through the price and calculation mechanisms. VariSales was built to manage finite configurations. Therefore, the maximum number of Applications is limited, the upper bound is defined with a constant Max_Applications=20, applied in the subfeature definition Applications.

In future work, direct support for compiling resource constraints into weight constraints rules should be added to efficiently and more proactively support the user in cases that are comparable to the example. The idea of this compilation was described inSoininen et al. (2001).

As a whole, the modeling proceeded smoothly and was able to capture the most relevant aspects. The user interface was semiautomatically generated. In our view, VariSales quite elegantly combines high-level configuration modeling, underlying reasoning, and semiautomatic generation of the user interface.

References

1. Hotz L, Felfernig A, Stumptner M, Ryabokon A, Bagley C, Wolter K. Configuration knowledge representation & reasoning. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:41–72. (Chapter 6).

2. Simons P, Niemelä I, Soininen T. Extending and implementing the stable model semantics. Artificial Intelligence. 2002;138(1–2):181–234.

3. Soininen T, Tiihonen J, Männistö T, Sulonen R. Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 1998;12(4):357–372.

4. Soininen, T., Niemelä, I., Tiihonen, J., Sulonen, R., 2001. Representing configuration knowledge with weight constraint rules. In: Provetti, A., Son, T.C. (Eds.), 1st International Workshop on Answer Set Programming: Towards Efficient and Scalable Knowledge (AAAI Technical Report SS-01-01), pp. 195–201.

5. Tiihonen J, Soininen T, Niemelä I, Sulonen R. A practical tool for mass-customising configurable products. In: Proceedings of the 14th International Conference on Engineering Design, Stockholm, Sweden, August 19–21, 2003, CDROM. 2003; p. 10 (Paper number: 1290).

6. Tiihonen J, Heiskala M, Anderson A, Soininen T. WeCoTin – a practical logic-based sales configurator. AI Communications. 2013;26(1):99–131.

¹Chapter 6.

²Chapter 6.