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

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

Part I. Introduction

Chapter 3. Configuration-Related Topics

Alexander Felferniga, Lothar Hotzb, Juha Tiihonenc and Claire Bagleyd, aGraz University of Technology, Graz, Austria, bHITeC e.V., University of Hamburg, Hamburg, Germany, cAalto University, Aalto, Finland, dOracle Corporation, Burlington, MA, USA

Abstract

Configuration has a number of related topics such as mass customization, software product lines, design, planning, recommender systems, software configuration, and product data management. For a discussion of mass customization, refer to Chapter 9; a discussion of software product lines can be found in Chapter 6. The other topics are discussed in this chapter.

Keywords

Knowledge-based Configuration; Related Topics; Design; Planning; Recommender Systems; Software Configuration; Version Management; Product Data Management

3.1 Design

Sabin and Weigel (1998) define configuration as “a special case of design activity where the artifact being configured is assembled from instances of a fixed set of well defined component types which can be composed conforming to a set of constraints.” Following the characterization of synthesis tasks (Brown and Chandrasekaran, 1989), configuration is often categorized as routine design (Günter and Kühn, 1999; Stumptner, 1997; see Figure 3.1).

image
FIGURE 3.1 Different types of design tasks: (1) designs are derived from a fixed set of component typesand related constraints (routine), (2) new components and constraints can be included within the scope of the design process (innovative), and (3) components and constraints are designed from scratch (creative). incdenotes incompatibility constraints.

Brown and Chandrasekaran (1989) describe routine design (design class 3) as a problem, where the specifications of objects, their properties, and compositional structures are already given, and the discovery of a solution is based on a known strategy. This characterization is similar to the definition of Sabin and Weigel (1998). An example of routine design is the quote generation for technical systems on the basis of a complete description of components, their properties, a compositional structure, and related constraints. If the limitations of routine designare not given in the domain, other possible categorizations are innovative design (design class 2) and creative design (design class 1 on the top of the scale). An example of innovative design is the creation of an upgrade version of a basic mobile phone type that–compared to the old model–includes additional features. An example of creative design is the artistic design of a new furniture line. From these examples, we can infer that transitions between design classes are smooth and subcategorizations can be introduced (Hotz and Vietze, 1995). For a detailed discussion of design tasks, refer to Brown and Chandrasekaran (1989).

3.2 Planning

Planning can be defined as a process of sequencing a set of activities in such a way that a defined goal can be accomplished. Thus, planning deals with the composition of actions whereas configuration deals with the composition of components. Both tasks are similar1with regard to the calculated results and the used problem solving approach. An example of how to translate a planning task into a corresponding configuration task is depicted in Figure 3.2.

image
FIGURE 3.2 Representing a planning task as a configuration task.

Solution spaces are in both cases restricted by constraints: in planning between actions and in configuration between components. A distinction between planning and configuration is the influence of temporal restrictions in planning situations (e.g., action a1 before a2 or a1 and a2 at the same time). The question “does a condition still hold after applying a planning operator?” is a main concern in planning tasks. It introduces additional complexity, which explains research interests in approaches that exploit elaborated heuristic search methods (Biundo et al., 1993; Edelkamp and Schrödl, 2012; Görz, 1993).

3.3 Recommender Systems

Recommender systems (Felfernig et al., 2007, 2013; Jannach et al., 2010; Ricci et al., 2011) support users in the process of finding and selecting products (items) from a given assortment. Examples of such items are movies, books, songs, financial services, apartments, and digital cameras. Configurators are often built with a similar goal in mind. However, a major difference between product configurators and recommender systems is the way in which product knowledge is represented (Falkner et al., 2011). Where configurators often operate on a configuration knowledge base, recommender systems typically operate on a table of explicitly defined solution alternatives. A reason for using a knowledge base is that the space of possible solutions makes an explicit representation impossible. The major commonality between recommenders and configurators is that both systems try to achieve the goal of proactively supporting users in finding a solution (configuration) that fits their wishes and needs. There are three basic approaches to the recommendation of items.

First, collaborative filtering (CF; Konstan et al., 1997) is based on the idea of word of mouth promotion. Such systems determine recommendations by identifying so-called nearest neighbors with a similar rating behavior (preference profile) compared to the current user. On the basis of this information, items are recommended that are not known to the current user. Second, content-based filtering (CBF; Pazzani and Billsus, 1997) is based on the idea of recommending items that are determined on the basis of the similarity between the preferences of the current user (properties of items already investigated by the user) and item properties extracted from item descriptions. An example of the application of content-based recommendation is the recommendation of web sites. Third,knowledge-based recommendation (KBR; Felfernig and Burke, 2008; Felfernig et al., 2006) recommends items on the basis of a predefined set of constraints (rules) and/or similarity metrics. The major difference compared to the approaches of CF and CBF is that in KBR deep knowledge about the product assortment is needed in order to be able to determine recommendations (this is not the case with CF and CBF approaches). For a more detailed discussion of recommendation technologies refer, for example, to Jannach et al. (2010)and Ricci et al. (2011).

Since we can observe an increasing demand for functionalities that proactively support configurator users, there is plenty of potential to exploit recommendation technologies to support the interaction with configuration systems (Falkner et al., 2011; Tiihonen and Felfernig, 2010). One such functionality is the recommendation of features. For example, due to the large number of questions, a recommender can act as a preselector of questions that should be posed to the user (see Table 3.1). Collaboratively selecting features is one approach to predict features that will be of interest for the user. This kind of recommendation can be implemented on the basis of collaborative filtering (Konstan et al., 1997). If we assume that a user in his/her current session has already selected and specified the features image and image, the most similar sessions (the four nearest neighbors) are the sessions image and image would be recommended as the next text feature to be specified by the user (image is the feature that has been selected by the majority of nearest neighbors). Other examples are the recommendation of feature values (Falkner et al., 2011; Tiihonen and Felfernig, 2010) and the recommendation of repair alternatives for inconsistent requirements (Felfernig et al., 2009).

Table 3.1

An example image matrix for collaborative feature recommendation (Falkner et al., 2011). The values of image denote the order in which features image have been specified by a user in session image.

Image

3.4 Software Configuration and Version Management

Configuration technologies originally evolved from hardware configuration (McDermott, 1982). Configuration can also be applied to software and software-intensive systems, due to the generality of the developed technologies. Software-intensive domains such as Car Periphery Supervision (CPS) require the combination of hardware and software systems. CPS systems monitor the local environment of a car on the basis of sensors installed around a vehicle. The measurement and evaluation of sensor data enables different kinds of applications. These can be grouped into safety-related applications such as pre-crash detection, blind spot detection, and adaptive control of airbags and seat belt tensioners; and comfort-related applications such as parking assistance and adaptive cruise control (Thiel et al., 2001). Due to the variety of involved hardware and software components and a high variety in the set of possible customer requirements, CPS becomes an interesting area for applying configuration methods (Geyer, 2002; Hotz et al., 2006). Examples of the application of configuration technologies for “pure” software configuration are discussed in Hotz et al. (2006), Männistö et al. (2001), Myllärniemi et al. (2005), and Tiihonen et al. (1998). Approaches to the configuration of software product lines (based on feature models) are discussed in Chapter 6.

Software Configuration Management (SCM) handles dependencies of software artifacts in the context of software development projects. In the majority of the cases, these artifacts are represented as files (see, e.g., Ylinen et al., 2002, for configuring Linux systems). Major functionalities are the creation of a new version of a software artifact, the restoration of partial (or complete) older versions, the merging of different versions, and notification services that keep developers informed about changes in the repository. As such, SCM is primarily applied in the context of software development processes whereas software configuration technologies focus more on the variability management of stable software artifacts. A major difference compared to configuration technologies is the lack of an abstract, declarative model of the source code being configured (Männistö and Sulonen, 1999). Knowledge-based systems (such as configuration systems) provide a more formal notion of consistency and completion than SCM systems (Tiihonen et al., 1998) and can give support in this issue. Further aspects related to Software Configuration Management are discussed in van der Hoek et al. (1995).

3.5 Product Data Management

Product Data Management (PDM) supports the definition and maintenance of information required to design, manufacture, and maintain products.2 Examples are specifications related to the manufacturing process, technical product data, and specifications of material needed for production purposes. Product parts stored in a PDM system are typically characterized with attributes such as part identifier, name of the supplier, price, and CAD drawings. PDM systems may be used to store configurations, derived documents, and bills of material created with configurators. Integration of a PDM system and a configurator for storing configurations can be realized directly or via an ERP system. A configurator and a PDM system often share some common product data: in the context of the working example (see Chapter 6), current hard disk and processor types could be added to the configuration model through PDM integration. PDM systems increasingly include facilities for configuring products, especially from the production configuration point of view. In this role, PDM systems can act as a kind of corporate knowledge repository that supports information interchange among users from, for example, marketing, sales, product development, production, and the customer.

3.6 Conclusion

In this chapter, we briefly discussed topics that are directly related to configuration. Distinctive features between configuration and these related topics are reasoning about temporal dependencies in planning, open configuration models in design, explicit representation of alternatives in recommender systems, explicit handling of dependencies in software configuration management, and flexible data management in product data management systems.

References

1. Biundo S, Günter A, Hertzberg J, Schneeberger J, Tank W. Planning and configuration. In: Görz G, ed. Introduction in Artificial Intelligence. Bonn, Paris, Reading: Addison-Wesley; 1993:767–828.

2. Brown D, Chandrasekaran B. Design Problem Solving – Knowledge Structures and Control Strategies Research Notes in Artificial Intelligence Series. London: Pitman Publishing; 1989.

3. Edelkamp S, Schrödl S. Heuristic Search – Theory and Applications. Waltham, MA: Academic Press; 2012.

4. Falkner A, Felfernig A, Haag A. Recommendation technologies for configurable products. AI Magazine. 2011;32(3):99–108.

5. Felfernig A, Burke R. Constraint-based recommender systems: technologies and research issues. In: ACM International Conference on Electronic Commerce (ICEC08), Innsbruck, Austria. 2008:17–26.

6. Felfernig A, Friedrich G, Jannach D, Zanker M. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC). 2006;11(2):11–34.

7. Felfernig A, Friedrich G, Schmidt-Thieme L. Guest editors’ introduction: special issue on recommender systems. IEEE Intelligent Systems. 2007;22(3):18–21.

8. Felfernig A, Schubert M, Friedrich G, Mandl M, Mairitsch M, Teppan E. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA. 2009:791–796.

9. Felfernig A, Jeran M, Ninaus G, Reinfrank F, Reiterer S. Toward the next generation of recommender systems: applications and research challenges. In: Tsihrintzis GA, Virvou M, Jain LC, eds. Multimedia Services in Intelligent Environments Advances in Recommender Systems. Springer 2013:81–98. Smart Innovation, Systems and Technologies vol. 24.

10. Geyer L. Configuring product families using design spaces. In: Integrated Design and Process Technology (IDPT-2002) Society for Design and Process Science, Pasadena, CA. 2002;9. (CD ROM).

11. Görz G. Introduction in Artificial Intelligence. Addison-Wesley 1993.

12. Günter A, Kühn C. Knowledge-Based Configuration – Survey and Future Directions. In: Puppe F, ed. XPS-99: Knowledge Based Systems, Proceedings Fifth Biannual German Conference on Knowledge Based Systems. Würzburg: Springer; 1999; Lecture Notes in Artificial Intelligence vol. 1570.

13. Hotz L, Vietze T. Innovative configuration in technical domains. In: PuK-95 – 9 Workshop Planen und Konfigurieren DFKI Saarbrücken, Kaiserslautern, Germany. 1995:59–68. (in German: Innovatives Konfigurieren in technischen Domänen).

14. Hotz L, Wolter K, Krebs T, et al. Configuration in Industrial Product Families – The ConIPF Methodology. Berlin: IOS Press; 2006.

15. Jannach D, Zanker M, Felfernig A, Friedrich G. Recommender Systems: An Introduction. Cambridge University Press 2010.

16. Konstan J, Miller B, Maltz D, Herlocker J, Gordon L, Riedl J. Grouplens: applying collaborative filtering to usenet news full text. Communications of the ACM. 1997;40(3):77–87.

17. Männistö T, Sulonen R. Evolution of schema and individuals of configurable products. In: Chen P, Embley D, Kouloumdjian J, Liddle S, Roddick J, eds. Advances in Conceptual Modeling – Proceedings of ECDM’99 – Workshop on Evolution and Change in Data Management. Versailles, France: Springer; 1999:12–23. Lecture Notes in Computer Science vol. 1727.

18. Männistö T, Soininen T, Sulonen R. Modeling configurable products and software product families. In: 17th International Joint Conference on Artificial Intelligence (IJCAI-2001) Workshop on Configuration, Seattle, Washington. 2001;64–70.

19. McDermott J. R1: a rule-based configurer of computer systems. Artificial Intelligence. 1982;19(1):39–88.

20. Myllärniemi V, Asikainen T, Männistö T, Soininen T. Kumbang configurator – a configuration tool for software product families. In: 19th International Joint Conference on Artificial Intelligence (IJCAI-05) Configuration Workshop, Edinburgh, Scotland, UK. 2005:51–56.

21. Pazzani M, Billsus D. Learning and revising user profiles: the identification of interesting websites. Machine Learning. 1997;27(3):313–331.

22. Ricci F, Rokach L, Shapira B, Kantor P. Recommender Systems Handbook. Springer 2011.

23. Sabin D, Weigel R. Product Configuration Frameworks – A Survey. IEEE Intelligent Systems. 1998;13(4):42–49.

24. Stumptner M. An overview of knowledge-based configuration. AI Communications. 1997;10(2):111–126.

25. Thiel S, Ferber S, Fischer T, Hein A, Schlick M. A case study in applying a product line approach for car periphery supervision systems. In: Proceedings of In-Vehicle Software 2001 (SP-1587), SAE 2001 World Congress, Detroit, Michigan. 2001;43–55.

26. Tiihonen J, Felfernig A. Towards recommending configurable offerings. International Journal of Mass Customization. 2010;3(4):389–406.

27. Tiihonen J, Lehtonen T, Soininen T, Pulkkinen A, Sulonen R, Riitahuhta A. Modelling configurable product families. In: Fourth WDK Workshop on Product Structuring, Delft, The Netherlands. 1998:29–50.

28. van der Hoek A, Heimbigner D, Wolf L. Does configuration management research have a future? In: Software Configuration Management – ICSE SCM-4 and SCM-5 Workshops Selected Papers. Seattle, Washington, USA: Springer; 1995:305–309. Lecture Notes in Computer Science vol. 1005.

29. White, A., Halpern, M., 2009. A Look at the Differences and Interactions Among PDM, PLM and MDM. Technical Report G00169693, Gartner.

30. Ylinen K, Männistö T, Soininen T. Configuring software products with traditional methods – case Linux Familiar. In: 15th European Conference on Artificial Intelligence (ECAI 2002), Configuration Workshop, Lyon, France. 2002;5–10.


1See also www.puk-workshop.de.

2Product Data Management nowadays is often discussed in context of the disciplines of Product Lifecycle Management (PLM) and Master Data Management (MDM). Discussing the relationship is outside the scope of this book. See, for example, White and Halpern (2009).