K-Model – Structured Design of Configuration Models Dr. Axel Brinkop1 and Dr. Thorsten Krebs2 and Hartmut Schlee3 Abstract.3 The purpose of this paper is to introduce the novel together with their interdependencies. We further use MS Excel to knowledge acquisition methodology K-Model. We describe the define data about available components according to the definition methodology itself and how it was applied within a project for of classification data as well as tabular dependencies, i.e. variant creating a prototype configuration application at J. Schmalz tables. The method describes a process consisting of workshops, GmbH. K-Model is supporting both the formalism of designing reviews and “offline” refinement steps in which the relevant configuration models on a conceptual level as well as the method to actually implement these models. Based on the experience that configuration knowledge for the product domain is acquired and configuration knowledge is tacit and distributed within the heads of actually implemented within a configuration model. several product experts’, the methodology is focusing on cross- J. Schmalz GmbH is a family-run company situated in Glatten, department communication about future goals of the configuration Germany. Schmalz is a leading global supplier of vacuum application. The visualization facilities of standard mind maps help technology in the fields of automation, handling and clamping them to achieve a common agreement and to focus on the product technology with an export quota of 50%, 15 subsidiaries abroad, domain rather than on knowledge representation formalisms. The and sales partners within 40 countries all over the world. When it methodology was successfully used in the project to set up a comes to automated production processes, Schmalz offers a wide configuration prototype for complex products in the area of range of individual vacuum components and related services. vacuum technology. Different vacuum systems can be operated in different environments, e.g. vacuum gripper systems are ready-to-connect 1 MOTIVATION modular systems for usage in robotic applications, vacuum handling systems are operated manually and ease the handling of A major challenge in realizing knowledge-based configuration work pieces and vacuum clamping systems offer short set-up times systems is the acquisition and formalization of configuration for CNC machining centers. knowledge. But knowledge acquisition is notoriously a very Schmalz is a very innovative company with permanent expensive process. Actually, most of the complexity of solving a readiness to implement and accept changes. A current change of configuration problem is said to lie in representing the domain the company is driven by investing in a quote generation process knowledge [2]. including configuration of vacuum products. The goal of this One of the main reasons for the complexity of knowledge change is to ease generating technically correct solutions for acquisition is that two types of expertise are required: knowledge complex configuration problems together with high quality quote about the product domain and dealing with the representation documents. The K-Model methodology was used to set up a language that is used for modeling the product domain. But very prototype quote generation application for complex configurable few persons are both domain expert and knowledge modeling products from the families of vacuum handling systems and expert. Thus, in practice the modeling task is carried out by one of vacuum clamping systems. the two engineers, probably being assisted by the other one. The remainder of this paper is organized as follows. In Chapter In this paper we introduce the knowledge acquisition 2 we describe the knowledge acquisition methodology K-Model, methodology K-Model. This methodology helps the knowledge i.e. both the formalism and the method, in more detail and give engineer to focus on the product domain rather than on knowledge mind map representation examples. Chapter 3 describes the representation formalisms. K-Model consists of formalism for application of K-Model within a real-life customer project, i.e. both designing the contents of a configuration model and a method for applying the formalism and method of K-Model for acquiring a acquiring configuration knowledge and actually creating the configuration model as well as implementing the acquired contents. contents. The formalism describes the types of knowledge required Chapter 4 concludes this paper with the major findings and in for creating a configuration system in a way that is well-founded Chapter 5 we present related work. on semantics but at the same time easily understandable for domain experts like product managers or sales engineers. We use mind map structures to visualize the relevant types of content, i.e. classification data, sales questions and the sales bill of materials 1 Brinkop Consulting, Oberschlettenbach, Germany, email: Brinkop@brinkop-consulting.com 2 encoway GmbH, Bremen, Germany, email: Krebs@encoway.de 3 J. Schmalz GmbH, Glatten, Germany, email: Hartmut.Schlee@schmalz.de Figure 1: The relations between structural knowledge, classification data and configuration knowledge. Experience shows that methodology is very well suited for workshops from several departments such as product management, 2 K-MODEL research & development, and sales. By applying the methodology K-Model is a methodology developed by Brinkop Consulting to a known domain, the participants are learning the formalism supporting both the formalism of designing configuration models very easily. In early phases the discussion is focusing on domain as well as the method to actually develop these models (“K” = specific configuration problems. There is no need for deep IT “Konfiguration”, German for configuration). It is not designed for background; the content of the mind map is understood by anybody any specific software but it is based on the approach to separately easily. It is a good basis to discuss alternative ways for solving the represent structural knowledge, configuration knowledge and configuration problem and to achieve a shared commitment. available components. The structural knowledge is a conceptual-level representation of 2.1 The Formalism the internal structure of the product to be configured; i.e. the product itself together with the parts from which it is assembled. The formalism distinguishes between the items (i.e. classification The options for each part are defined in the available components data of available components), the questions (i.e. sales-relevant themselves. Structural knowledge and available components are configuration questions) and the resulting sales bill of material (i.e. strongly related, though. The structural knowledge is expressed as proposal items). a hierarchy of classes, each class defined by a set of attributes. Inheritance of attributes is assumed. Every available component is an instance of a class with given attribute values. The configuration 2.1.1 The Items knowledge represents knowledge about dependencies and methods The tag ITEMS introduces the class hierarchy of available to determine components. Figure 1 illustrates the corresponding components. Below the tag ATTRIBUTES introducing the relations. The result of the configuration process is a sales bill of classifying attributes with their data type, possible values and material consisting of well-defined instances from these classes. In translations and are listed. The optional tag SUBTYPES marks the short, the structural knowledge defines the classes; the available classes of the next hierarchy level. The attributes are inherited components are defining the instances. along the hierarchy, i.e. all attributes of higher levels are known as K-Model assumes that the configuration model and the well. Structural sub-components might be defined using the tag underlying configuration engine are separated. There is no need HAS-PARTS. (and no possibility) to express specific solution strategies. It is The data about available components is defined in so-called assumed that the configuration engine can interpret the selection lists in MS Excel format. The structure of the selection dependencies specified. No specific configuration software is lists must be consistent with the structure defined herein. targeted; several commercial configuration engines can handle configuration problems designed with the K-Model methodology. K-Model is evolved by Brinkop Consulting in a multitude of projects. It was learned that configuration knowledge is distributed on several persons, each focusing on a different perspective of the configuration task. The challenge is not to acquire the configuration knowledge but to achieve a shared commitment of the way how to solve the configuration task at hand. Therefore K- Model concentrates on cross-department communication. The methodology addresses product experts with no specific IT skills. The formalism allows informal descriptions of configuration details as well as formal specifications. The description of the configuration model is based on a mind map with special keywords and structure. The tool of choice is Freeplane4, which is open source and easy to use. 4 http://freeplane.sourceforge.net/ Figure 2: The ITEMS. 2.1.2 The Catalog Tags for language specific translations of the variables are included as well (LANG: en, LANG: de, etc.). The catalog is the starting point for the user in the quote generation process. A user can do both, select completely defined (standard) products or configure an individual product that consists of a set of 2.1.4 The Sales Bill of Material items. Both types of products can be included in a quote. The catalog is structured by categories; each category contains either The result of the configuration process is a sales bill of material item classes or other categories. An item may be assigned to tagged as BOM. The bill of material can be structured to any level several categories; i.e. the assignment must not be unique. The user desired, the “leaves” are instances of the classes below ITEMS. can find such an item on several paths. Hereafter the “leaves” are called in short “positions”. The tags DISPLAY and SEARCH are used to define the Every position is defined by a query. A query to select a attributes to be shown or searched respectively. position consists of the specification of the class to be searched and conditions to be met by the attributes of the position. It is required that the assignment is unique. 2.1.3 The Questions To express relations like “select the drive with the lowest power which is higher as required by x, queries can be specified Variables are specifying the object to be configured. They are using the combination of the tags ORDER-BY with FIRST or organized in classes below the tag QUESTIONS. In fact, variables LAST with the same meaning as in SQL. are grouped in classes defining the user interaction. For easy handling variables of a class might be organized additionally in topics. This organization results in a three level hierarchy “class- topic-attribute” which can be found again in the formal names of variables. The use of just three levels is a simplification which was not perceived as a restriction in past projects. K-Model assumes that there is no additional specification for the user interface; the variables are presented to the user “as they Figure 4: QUERY in the BOM. are”. Input variables are tagged as EDIT, SELECT, CHECKBOX etc. and output variables as OUTPUT or HIDDEN. The organization in classes and topics is assumed to be used for 2.2 The Method organizing the questions, for instance in tabs. The method describes the steps that are necessary to set up a configuration model using the formalism presented in the previous section. The following sections each describe a step of the process that are carried out during workshops or reviews, according to figure 5. 2.2.1 Capture variables The model design process starts with a kick-off workshop to define the scope of the model and to get an idea about the configuration problem. In a kind of brainstorming the relevant characteristics are collected and captured in the mind map. These characteristics are called variables in the following. The objective is not to describe the configuration problem formally but to gain the key variables for the problem. After the first phase the variables are discussed more in detail, e.g. whether a variable is an input or an output. In case of an input, does the value come from a fixed set of values or is a user free to enter any value. In case of an output it is discussed how the value can be computed. 2.2.2 Organize variables Variables describing the same object should be placed as attributes of the same class. K-Model has the concept of a “topic” to organize attributes of a class in another level. This allows easily handling classes with a large number of attributes. As already stated, it is assumed that the organization of the Figure 3: The QUESTIONS. variables directly influences the user interface. Variables belonging to the same topic are represented to the user at the same time: e.g. classes in tabs and topics as groups of decisions. Figure 5: The cycle of workshops and reviews for designing configuration models. In case of automatic selection, the components must have 2.2.3 Set up component selection criteria mutually exclusive sets of attribute values. Each query should have exactly one hit. This requirement can be relaxed when there is a Available components are organized in classes according to the scenario of interactive selection by the user. In that case there defined ITEMS. Individual components as parts of the might be multiple hits of a query, but user must have the possibility configuration solution are selected by a set of specific criteria. to distinguish between the components. Ideally, there is either a These criteria make up the characteristic attributes of the text or a picture describing the components. components’ class. For every component class these characteristic attributes have to be listed and their domains specified. Especially for discrete value 2.2.7 Formalize dependencies domains, every possible value has to be specified. Finally the specifications of the variables and the dependencies are written down formally using formulas, algorithms and query 2.2.4 Identify dependencies statements. This step is required for ensuring that the model can be implemented with the configuration software. It is the dependencies between variables that turn a configuration It is important to keep the informal description as well for problem into a hard problem. There are several ways in which documentation purposes and to control the formalization and to variables can influence one another. The calculation of the keep the ability for an easy discussion. following variables’ properties may be based on other variables:  Value  Default value 3 APPLICATION OF K-MODEL IN THE  Existence condition CASE OF SCHMALZ  Selection of component type (i.e. the type of class) It is assumed that the configuration engine selected for the This section describes how K-Model was applied at J. Schmalz implementation exposes default values to the user and does not GmbH to acquire the relevant configuration knowledge and for assign defaults directly to the variable. realizing a prototype configuration application. 2.2.5 Analyze dependencies 3.1 Procedure in the Workshops After the informal definition dependencies are analyzed. As According to the K-Model method the relevant configuration already stated, the variables (“questions”) are describing classes of knowledge for realizing a configuration application was acquired user interaction. Variables which have a strong relationship should during a kick-off workshop and follow-up review workshops. be placed in the same class. This reduces complexity for the model The configuration team was set up from product manager, sales as well as complexity of user interaction. manager, product data management and K-Model expert. The A good tool for analysis is a dependency matrix containing the knowledge acquisition process is driven by the K-Model expert and configuration variables as header for rows and columns. A field (x, supported by all other team members. During all workshops the K- y) contains a cross when variable x influences variable y. The Model expert takes notes visible for every participant using the K- distribution of the crosses visualizes the dependencies. Model mind map. The kick-off workshop started with specifying the scope of the configuration model. Two distinct product families were chosen for 2.2.6 Classify available components realizing the prototype application in order for being able to assess Available components are organized in classes with characteristic the results independent from a single product domain. After this the attributes; every individual component is classified by assigning K-Model methodology was applied by capturing variables, values to its attributes. Available components are selected by their organizing variables, setting up components’ selection criteria, and attribute values; i.e. they represent the providing “function” within identifying dependencies. This work is done in a kind of the attributes. “brainstorming” style with documenting every statement possibly multiple constraints. A condition describes a situation of informally in the K-Model mind map. the configuration solution that must be given for the constraints to After the kick-off workshop the mind map was refined by be evaluated. engcon offers a wide variety of pre-defined adding formalized definitions according to the informal notes that constraints that restrict a given set of concept attributes, including were taken within the workshop. The individual components are formulae and tables. Simple dependencies (such as greater, less, classified and the specifications and the dependencies are equals, and so on) and formulae can easily be created using K- formalized. This is typically done “offline”; the K-Model expert is Build. Tabular dependencies from K-Model can also be mapped to extending the mind maps and dependencies accordingly and the K-Build’s Excel representation with little effort. product managers or other persons at the customer’s site define the The configuration application for Schmalz was set up in two available components within MS Excel sheets. distinct steps. In a first step we created a proof-of-concept for The resulting mind map and data in Excel sheets were reviewed which the least effort should be used. This proof-of-concept was in some follow-up review workshops by the same team. Just a few the configuration model running in K-Build’s test environment K- cycles of the design process were required to extend the mind map Test. In a second step we realized the configuration application and MS Excel documents for reaching a level that satisfies all full-scale: with stable data exchange interfaces and full graphical participants. After that the model was released for realization. user interface. Hence, the data about available components was The main point of discussion in the workshops at J. Schmalz received in two different ways within the respective steps. GmbH was about the targeted user group. Should the product 1. In the proof-of-concept step the product data was transferred configurator be designed for the product novice with only little from the K-Model Excel format to the K-Build Excel format. knowledge about Schmalz’ products and enrich the application 2. In the full-scale step the configuration application was set up with product details or should it rather address the expert and thus using encoway’s standard architecture. The product data focus on few decisions without explicit marketing information? At contained in the Excel sheets was converted into encat, which the end it was decided to assist both of them. The system should is encoway’s standard format for realizing media-neutral guide the novice and should not stop the expert from realizing the master data exchange, based on a well-defined xml structure. configuration he has in mind. The K-Model Excel sheets containing product data can be transformed into a corresponding K-Build Excel sheet with little manual effort. This way, the available components are imported 3.2 Realization at encoway into the configuration model as specializations of concepts that encoway received the mind maps and Excel sheets that are the stem from the classification data. This first step was carried out for result of applying the K-Model methodology. The documents testing purposes. contain a formal description of the product structure and The encat xml document containing product data was imported dependencies together with the available component for two into the so-called catalogue. encat documents also contain all product families. Our modeling experts were directly able to use relevant translations and pricing information, which is relevant for this structured information for modeling the products within the application user interface and for quote generation, i.e. during encoway’s modeling environment K-Build. run-time, not for creating the configuration model during build- K-Build is web-based application for formalizing configuration time. Instead, encoway configuration models are typically knowledge consisting of structure-based modeling facilities, i.e. language-neutral and do not contain the available components or concepts together with their attributes arranged in taxonomy and pricing information. The catalogue is a single place for all this partonomy, as well as constraint definitions. This modeling tool information. Technically, it is a database that comes with an contains a test environment which uses the inference engine advanced API for querying the different types of data during run- engcon for interpreting the configuration knowledge. For detailed time. information about structure-based configuration and engcon the While product information, including the translations and interested reader is referred to [4] and [3], respectively. pricing information change over time, the physics, on which the The structure within a K-Model mind map can be mapped product configuration is based, typically stays stable. The physics directly to concepts representing separate branches within the is represented within the configuration model while the actual taxonomy: one each represents the sales questions, the components are not. The major benefit of using encat as stable data classification data and the sales bill of materials: exchange interface is thus that the configuration model need not be  A group of sales questions is mapped to a single concept; the changed when importing new product data. questions themselves are mapped to attributes of that concept. For realizing the Schmalz configuration application we use encoway’s quoting process-supporting tool QuoteAssistant. The  The classification data is mapped to concepts and the available QuoteAssistant is a web-based application for browsing catalogue components defined in MS Excel sheets are imported into content, configuring products, creating quoting structures together lower levels of the specialization hierarchy; i.e. as with pricing and generating high quality quote documents; all in specializations of those concepts. one place. The QuoteAssistant contains a standard user interface  The sales bill of materials (also called bom) can be structured design for displaying concepts and their attributes within a tab into groups. Each group is mapped to a concept. The structure using a widget collection containing checkboxes, select configuration solution consists of instances of the available boxes or text input fields. This means that, when treating all components which are modeled as parts of the bom group concepts that are modeled as parts of the K-Model questions as structure. tabs, the placement of sales questions is determined by their attributes and no extra definition for user interface is required. The dependencies within a K-Model mind map can be mapped The user is free in structuring configurable products and to so-called rules, each being equipped with a condition and available components from the catalogue within folders of a quoting structure. The result of the quoting process is such a 5 RELATED WORK structure together with pricing and conditions. This quote result can be exported to a MS Word or PDF documents via the tool K- Because knowledge acquisition in the environment of knowledge- Document. This tool allows using pre-defined MS Word templates based configuration systems is notoriously a very expensive and enriching them with the configuration results, content from a process, there is other work concentrating on this task. Support for CRM system (such as address data) and from the catalogue knowledge acquisition tasks ranges from propose-and-revise (product information or images) automatically during run-time. techniques that help users in deciding on correctness to graphical representation in form of UML class diagrams or mind maps. The work described in [7] explicitly targets to support the task 4 CONCLUSION of knowledge acquisition for configuration knowledge bases with a propose-and-revise strategy. It is implemented in the knowledge In this paper we have shown how the knowledge acquisition acquisition tool EXPECT, which uses LOOM, a knowledge methodology K-Model helps a knowledge engineer to focus on the representation system based on description logics. The focus of this product domain rather than on knowledge representation work is on correctness of the underlying knowledge and does not formalisms while creating a configuration model. The visualization take graphical representation into account. facilities of standard mind maps ease the creation of configuration In [6] a UML representation for configuration knowledge bases models for product managers and sales personnel who are typically is introduced for the purpose of enhancing sharing, distribution and not experts in the area of knowledge representation. Especially cooperation within the use configuration knowledge. UML within workshops where persons with different backgrounds stereotypes are defined to represent the specifics of configuration together acquire the relevant knowledge for a configuration such as concepts, attributes, taxonomy and partonomy. Constraints applications this informal mind map representation is a valuable are defined using OCL. In [8] the authors bring the idea one step tool. further by introducing a set of rules for transforming UML models The results which are produced by the analysis steps described into configuration knowledge based on description logics such as in Section 2.2 may seem rather tentative at first sight. However, the OIL or DAML+OIL. This work explicitly aims at supporting the results remain stable once the process of designing a configuration knowledge acquisition bottleneck with graphical representation as model has gone through a small number of design cycles (see also a frontend and can thus be seen similar to the K-Model approach, Figure 5). K-Model was already used to analyze and design although K-Model prefers mind maps over UML diagrams. configuration models for roughly 20 domains, mostly of very The authors of [5] also use mind map structures to support different nature and size. The largest domains consist of up to 2000 knowledge engineers. However, their work focuses on formalizing, variables that are relevant for product configuration within this sharing and reusing experiences of past projects in order to help domain. We thus see this as a significant number of cases to call K- avoiding mistakes that these projects have already encountered. Model a success for supporting the process of analyzing a Their work differs from ours in the sense that they use mind maps configuration domain and designing a respective configuration to capture and represent project experience while we use mind model. For encoway, however, the Schmalz configurator is the first maps to capture and represent configuration knowledge. application of a K-Model. But nonetheless, the input in form of The methodology K-Model is novel in the way that is explicitly well-designed mind maps and Excel sheets significantly improved targets to support non-experts during the acquisition of setting up a configuration model from scratch. configuration knowledge by using mind maps as a graphical An extension of K-Model that is currently under development is frontend. Furthermore, the K-Model explicitly distinguishes master modularizing the mind map in multiple sub-maps. With this data and product structure, configuration decisions and the approach it is possible to describe smaller parts of a configuration configuration solution. It defines the syntax and semantics of that can be reused (multiple times) within larger configuration usable mind map structures as well as the modeling process, i.e. contexts. The modularization also enhances keeping an overview how to use the mind maps in workshop situations together with of large configuration domains. non-experts such as product managers or sales personnel. For J. Schmalz GmbH, K-Model was applied while creating a working prototype configuration application. It took just a few workshops with product managers and sales personnel to set up the K-Model mind maps and MS Excel. This input data was of high quality and could be directly used by encoway modeling experts for creating a configuration model of the product domain. Schmalz is now able to fully benefit from the configuration application that was set-up using the K-Model knowledge acquisition methodology. Applying K-Model within this project was successful in that all relevant persons – including product managers, sales personnel and technicians – were able to focus on the specific characteristics of the desired configuration application without extra effort for learning representation facilities. The methodology significantly increased the efficiency of cross- department communication and reduced the time-to-prototype during realization. REFERENCES [1] A. Brinkop. Variantenkonstruktion durch Auswertung der Abhängigkeiten zwischen den Konstruktionsbauteilen, Dissertationen zur Künstlichen Intelligenz, Band 204, Infix, St. Augustin, 1999. [2] D. Sabin and R. Weigel. Product Configuration Frameworks – a Survey. IEEE Intelligent Systems, 13(4):42–49, 1998. [3] O. Hollmann et al. EngCon: A Flexible Domain-independent Configuration Engine. In: Proceedings of Configuration (ECAI 2000- Workshop):94–96, 2000. [4] C. Ranze et al. A Structure-based Configuration Tool: Drive Solution Designer (DSD), In: Proceedings of AAAI02 / IAAI02: 845–852, 2002. [5] C.-S. Chen and Y.-C. Lin. Enhancing Knowledge Management for Engineers Using Mind Mapping in Construction, New Research on Knowledge Management Technology, Dr. Huei Tse Hou (Ed.), ISBN: 978-953-51-0074-4, 2012. [6] A. Felfernig et al. Configuration Knowledge Representation Using UML/OCL, Lecture Notes in Computer Science, Volume 2460, 91- 108, 2002. [7] S. Ramachandran, Y. Gil. Knowledge Acquisition for Configuration Tasks: The EXPECT Approach. In: Proceedings of Configuration (AAAI 1999-Workshop):29–34, 1999. [8] A. Felfernig at al. UML As Knowledge Acquisition Frontend for Semantic Web Configuration Knowledge Bases, In: RuleML 2002 – Proceedings of the International Workshop on Rule Markup Languages for Business Rules on the Semantic Web, Michael Schröder and Gerd Wagner (Eds.), Volume 60, 2002.