Knowledge-based Configuration From Research to Business Cases

Citation preview

Knowledge-Based Configuration

This page is intentionally left blank

Knowledge-Based Configuration From Research to Business Cases

Edited by Alexander Felfernig Lothar Hotz Claire Bagley Juha Tiihonen

AMSTERDAM฀•฀BOSTON฀•฀HEIDELBERG฀•฀LONDON฀ NEW฀YORK฀•฀OXFORD฀•฀PARIS฀•฀SAN฀DIEGO฀ SAN฀FRANCISCO฀•฀SINGAPORE฀•฀SYDNEY฀•฀TOKYO฀

Morgan฀Kaufmann฀is฀an฀imprint฀of฀Elsevier

Acquiring Editor: Meg Dunkerley Editorial Project Manager: Heather Scherer Project Manager: Punithavathy Govindaradjane Designer: Matthew Limbert Morgan Kaufmann is an imprint of Elsevier 225 Wyman Street, Waltham, MA 02451, USA Copyright © 2014 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. Library of Congress Cataloging-in-Publication Data Knowledge-based configuration from research to business cases / edited by Alexander Felfernig, Lothar Hotz, Claire Bagley, Juha Tiihonen. pages cm Includes bibliographical references and index. ISBN 978-0-12-415817-7 (alk. paper) 1. Expert systems (Computer science) I. Felfernig, Alexander, editor of compilation. QA76.76.E95K555442 2014 006.3’3--dc23 2013043355 British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library ISBN: 978-0-12-415817-7 Printed and bound in the United States of America 14 15 16 17 18 10 9 8 7 6 5 4 3 2 1

For information on all MK publications visit our website at www.mkp.com

Contents Acknowledgments............................................................................................................................... xiii About the Editors ..................................................................................................................................xv List of Contributors .............................................................................................................................xvii Foreword ..............................................................................................................................................xxi

PART 1 INTRODUCTION CHAPTER 1 Motivation for the Book.................................................................3 1.1 What Is Configuration? ................................................................................................3 1.2 Why Use Configuration Technologies? .......................................................................6 1.3 Why Read This Book? .................................................................................................6 References....................................................................................................................7

CHAPTER 2 A Short History of Configuration Technologies................................................................................9 2.1 2.2 2.3 2.4 2.5

Rule-based Configurators ............................................................................................9 Early Model-based Configurators ..............................................................................10 Mainstream Configuration Environments ..................................................................11 Mass Customization Toolkits.....................................................................................13 Conclusion .................................................................................................................14 References..................................................................................................................15

CHAPTER 3 Configuration-Related Topics.......................................................21 3.1 3.2 3.3 3.4

Design ........................................................................................................................21 Planning .....................................................................................................................22 Recommender Systems ..............................................................................................23 Software Configuration and Version Management ..............................................................................................................24 3.5 Product Data Management ........................................................................................25 3.6 Conclusion .................................................................................................................25 References..................................................................................................................25

CHAPTER 4 Benefits of Configuration Systems ................................................29 4.1 Introduction................................................................................................................29 4.2 Challenges and Benefits .............................................................................................29 4.3 Conclusion .................................................................................................................32 References..................................................................................................................32

v

vi

Contents

CHAPTER 5 Overview of the Book ..................................................................35

PART 2 BASICS CHAPTER 6 Configuration Knowledge Representation and Reasoning ..................................................................................41 6.1 6.2 6.3 6.4 6.5 6.6

Introduction................................................................................................................41 Constraint-Based Knowledge Representation ...........................................................43 Graphical Knowledge Representation .......................................................................52 Logic-Based Knowledge Representation...................................................................59 Comparison of Knowledge Representations..............................................................66 Conclusion .................................................................................................................68 Acknowledgments .....................................................................................................68 References..................................................................................................................68

CHAPTER 7 Conflict Detection and Diagnosis in Configuration .........................73 7.1 7.2 7.3 7.4 7.5

Introduction................................................................................................................73 Example .....................................................................................................................74 Determining Minimal Conflict Sets ...........................................................................75 Determining Minimal Diagnoses ...............................................................................79 Conclusion .................................................................................................................86 Acknowledgments .....................................................................................................86 References..................................................................................................................86

CHAPTER 8 User Interfaces for Configuration Environments ............................89 8.1 8.2 8.3 8.4 8.5

Introduction................................................................................................................89 Design Principles for Configurator User Interfaces...................................................90 Technological Issues ..................................................................................................92 Usability Issues in Configurator User Interface Development ................................103 Conclusion ...............................................................................................................103 Acknowledgments ...................................................................................................104 References................................................................................................................104

CHAPTER 9 Core Capabilities of Sustainable Mass Customization ..........................................................................107 9.1 9.2 9.3 9.4 9.5

Introduction..............................................................................................................107 Solution Space Development ...................................................................................108 Robust Process Design.............................................................................................112 Choice Navigation ...................................................................................................113 Conclusion ...............................................................................................................117 References................................................................................................................117

Contents

vii

CHAPTER 10 Smarthome Configuration Model ................................................121 10.1 10.2 10.3 10.4 10.5 10.6 10.7

Introduction..............................................................................................................121 Building Automation Systems: Domain ..................................................................122 Configuration Model: Structure ...............................................................................123 Configuration Model: Constraints ...........................................................................129 Configuration Model: Configuration Workflow.......................................................132 Characteristics of the Smarthome Model ................................................................134 Conclusion ...............................................................................................................135 References................................................................................................................135

PART 3 ADVANCED TOPICS CHAPTER 11 Knowledge Engineering for Configuration Systems......................139 11.1 11.2 11.3 11.4 11.5

Introduction..............................................................................................................139 The Configurator Development Life Cycle .............................................................140 Debugging Configuration Knowledge Bases ...........................................................145 Organizational Challenges .......................................................................................150 Conclusion ...............................................................................................................151 References................................................................................................................153

CHAPTER 12 Redundancy Detection in Configuration Knowledge.....................157 12.1 12.2 12.3 12.4 12.5 12.6

Introduction..............................................................................................................157 An Example Configuration Knowledge Base ..........................................................159 Determining Redundant Constraints........................................................................160 CoreDiag ..................................................................................................................162 Evaluation ................................................................................................................163 Conclusion ...............................................................................................................164 Acknowledgments ...................................................................................................164 References................................................................................................................165

CHAPTER 13 Personalized Configuration .......................................................167 13.1 13.2 13.3 13.4 13.5

Introduction..............................................................................................................167 Example ...................................................................................................................168 Integrating Recommendation Technologies to Configurators .................................170 Research Challenges ................................................................................................176 Conclusion ...............................................................................................................177 References................................................................................................................177

CHAPTER 14 Consumer Decision-Making and Configuration Systems ..............181 14.1 Introduction..............................................................................................................181 14.2 Decoy Effects ...........................................................................................................182

viii

Contents

14.3 Serial Position Effects ..............................................................................................185 14.4 Status Quo Effect .....................................................................................................187 14.5 Conclusion ...............................................................................................................188 References................................................................................................................188

CHAPTER 15 Configuration-Related Research Challenges ...............................191 References................................................................................................................193

PART 4 CASE STUDIES CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry .............199 16.1 16.2 16.3 16.4 16.5 16.6

Introduction..............................................................................................................199 Domain: Railway Interlocking Systems ..................................................................200 Requirements ...........................................................................................................204 Techniques ...............................................................................................................206 Results......................................................................................................................208 Conclusion ...............................................................................................................209 References................................................................................................................209

CHAPTER 17 Tacton: Use of Tacton Configurator at FLSmidth ..........................211 17.1 17.2 17.3 17.4 17.5 17.6 17.7 17.8

Introduction..............................................................................................................211 FLSmidth Company Introduction ............................................................................211 Cement Plants ..........................................................................................................212 The Choice of Tacton Configurator .........................................................................213 Advantages and Requirements of Constraint-Based Configuration ........................214 Implementing Tacton Configurator at FLSmidth.....................................................215 Benefits ....................................................................................................................217 Conclusion ...............................................................................................................218 Acknowledgments ...................................................................................................218 References................................................................................................................218

CHAPTER 18 encoway: From ERP-Based to Sales-Oriented Configuration .........219 18.1 18.2 18.3 18.4

Introduction: ERP-Based Configuration ..................................................................219 Sales-Oriented Configuration ..................................................................................220 Configurator Application: sellAIR at Boge .............................................................223 Conclusion ...............................................................................................................227 References................................................................................................................227

CHAPTER 19 Kapsch: Reconfiguration of Mobile Phone Networks ...................229 19.1 Introduction..............................................................................................................229 19.2 Domain Requirements .............................................................................................230

Contents

ix

19.3 SIMOA Approach ....................................................................................................233 19.4 Business Cases .........................................................................................................238 19.5 Conclusion ...............................................................................................................239 Acknowledgments ...................................................................................................239 References................................................................................................................239

CHAPTER 20 Configuring and Generating Technical Documents ......................241 20.1 20.2 20.3 20.4 20.5 20.6

Introduction..............................................................................................................241 Defining Model-Based Product Lines .....................................................................242 Industrial Case Example: Customizing Technical Documentation .........................243 Modeling Document Variability ..............................................................................244 Tool Support for Document Configuration and Generation ....................................246 Conclusion ...............................................................................................................248 Acknowledgments ...................................................................................................249 References................................................................................................................249

CHAPTER 21 Configuring Services and Processes ..........................................251 21.1 21.2 21.3 21.4

Introduction..............................................................................................................251 Sales Configuration of Services ...............................................................................252 Process Configuration ..............................................................................................255 Conclusion ...............................................................................................................258 Acknowledgments ...................................................................................................258 References................................................................................................................259

PART 5 CONFIGURATION ENVIRONMENTS CHAPTER 22 S'UPREME ................................................................................263 22.1 22.2 22.3 22.4

Introduction..............................................................................................................263 System Architecture and Technological Background ..............................................263 Modeling of the Working Example..........................................................................265 Conclusion ...............................................................................................................269 References................................................................................................................269

CHAPTER 23 encoway ..................................................................................271 23.1 23.2 23.3 23.4 23.5 23.6 23.7

Introduction..............................................................................................................271 History and Scientific Basis .....................................................................................271 Modeling of the Working Example..........................................................................272 System Integration ...................................................................................................275 Data Integration .......................................................................................................276 Quote Generation Process........................................................................................277 Conclusion ...............................................................................................................278 References................................................................................................................278

x

Contents

CHAPTER 24 KONWERK ................................................................................281 24.1 24.2 24.3 24.4 24.5 24.6

Overview ..................................................................................................................281 Modeling of the Working Example..........................................................................282 Enhancement Modules.............................................................................................287 Implementation ........................................................................................................288 Applications .............................................................................................................290 Conclusion ...............................................................................................................293 Acknowledgments ...................................................................................................293 References................................................................................................................293

CHAPTER 25 WeeVis ....................................................................................297 25.1 25.2 25.3 25.4 25.5

Introduction..............................................................................................................297 Modeling of the Working Example..........................................................................298 User Interface...........................................................................................................302 Related Work ...........................................................................................................303 Conclusion ...............................................................................................................305 Acknowledgments ...................................................................................................305 References................................................................................................................306

CHAPTER 26 VariSales .................................................................................309 26.1 26.2 26.3 26.4 26.5

Introduction..............................................................................................................309 Modeling of the Working Example..........................................................................309 Price and Hard Disk Capacity..................................................................................313 User Interface Modeling and Generation.................................................................317 Conclusion ...............................................................................................................317 Acknowledgments ...................................................................................................318 References................................................................................................................318

CHAPTER 27 Product Configuration in SAP: A Retrospective ...........................319 27.1 Introduction..............................................................................................................319 27.2 Expert Systems (XPS) .............................................................................................320 27.3 Declarative Knowledge Representation and Constraints in XPS in the 1980s .................................................................................................321 27.4 The Manufacture of Variants: A Configuration Problem .........................................326 27.5 A Productively Used XPS: The SAP (OS/2) Configurator ......................................328 27.6 Making It Mainstream: The SAP Variant Configurator (SAP VC)..........................330 27.7 The SAP IPC (Internet Pricing and Configuration) .................................................332 27.8 Conclusion ...............................................................................................................334 Acknowledgments ...................................................................................................335 References................................................................................................................335

Contents

xi

PART 6 APPENDIX Appendix ......................................................................................................341 A.1 A.2 A.3 A.4 A.5 A.6

Conferences and Workshops .......................................................................................................341 Open-Source CSP, ASP, and SAT Solvers ...................................................................................342 Configuration Environments .......................................................................................................343 Benchmarks .................................................................................................................................343 Lexicons and Databases ..............................................................................................................344 Journal Special Issues..................................................................................................................344

Author Index .................................................................................................345 Subject Index ...............................................................................................353

This page is intentionally left blank

Acknowledgments We want to thank all the reviewers who helped to make this book a high-quality contribution to field of knowledge-based configuration. We would like to especially thank Michel Aldanondo and Albert Haag for their efforts in reviewing this book. Alexander Felfernig, Lothar Hotz, Claire Bagley, and Juha Tiihonen

xiii

This page is intentionally left blank

About the Editors Alexander Felfernig has been a full professor at the Graz University of Technology (Austria) since March 2009; he received his PhD in Computer Science from the University of Klagenfurt. Currently, he directs the Applied Software Engineering (ASE) research group at the Institute of Software Technology. His research interests include configuration systems, recommender systems, modelbased diagnosis, software requirements engineering, different aspects of human decision-making, and knowledge acquisition methods. Alexander Felfernig has published numerous papers in renowned international conferences and journals (e.g., AI Magazine, Artificial Intelligence, IEEE Transactions on Engineering Management, IEEE Intelligent Systems, Journal of Electronic Commerce) and is a coauthor of the book Recommender Systems, published by Cambridge University Press. He also acted as an organizer of international conferences and workshops such as the ACM International Conference on Recommender Systems and the International Symposium on Methodologies for Intelligent Systems. Currently, he is a member of the Editorial Board of Applied Intelligence and the Journal of Intelligent Information Systems. Lothar Hotz is a senior researcher at the Hamburg Informatics Technology Center (HITeC e.V.) located at the University of Hamburg, Germany; he received his PhD in Computer Science from the University of Hamburg. He has participated in several national and European projects related to topics of configuration, knowledge representation, constraints, diagnosis, scene interpretation, requirements engineering, parallel processing, syntactic and semantic search, and object-oriented programming languages. Lothar has published numerous scientific papers about these topics. Besides other books, he is co-author of Configuration in Industrial Product Families, published by IOS Press. Lothar is furthermore active in the German national knowledge-based configuration community (PuK) and in the international knowledge-based configuration community. Claire Bagley has been the Director of the Oracle Advanced Constraint Technology (ACT) organization since June 2009. She manages the research and development of the Oracle ACT product, which supplies constraint solutions for Oracle applications. In addition, she is the author or co-author of numerous patents in Constraint Programming and in the Configuration application domain. Her research and development interests include configuration systems, planning and scheduling systems, as well as all application domains that may benefit from constraint programming and mathematical programming solutions. Claire also acts as an organizer and committee member in international conferences including The European Conference on Artificial Intelligence (ECAI), The International Joint Conferences on Artificial Intelligence (IJCAI), The International Conference on Integration of Artificial Intelligence (AI) and Operations Research (OR) Techniques in Constraint Programming, and The International Conference on Principles and Practice of Constraint Programming. Juha Tiihonen is a researcher at Aalto University, School of Science. His research interests include product and service configuration in various forms, including modeling, configurators, operations management aspects of business processes based on product and service configuration, design for configuration, and recommendation of configurable offerings. He has published numerous articles on these subjects, and he is an active member of the scientific community of knowledge-based configuration.

xv

xvi

About the Editors

Additional research interests stem from supporting service business of equipment suppliers based on advanced utilization of information about their service base that includes both their and their competitor’s product individuals. What are key decisions in the context of services such as “full service” or “operate and maintain”? What information is required and how do we get it? How do we model that information? How do we process it into actionable form?

List of Contributors Andreas Anderson Variantum, Espoo, Finland Claire Bagley Oracle Corporation, Burlington, MA, USA Morten H. Bennick FLSmidth, Copenhagen, Denmark Paul Blazek cyLEDGE, Vienna, Austria Sanja Boltek Kapsch Carrier Com, Vienna, Austria Andreas Falkner Siemens AG Österreich, Vienna, Austria Alexander Felfernig Graz University of Technology, Graz, Austria Gerhard Friedrich Alpen-Adria Universität Klagenfurt, Klagenfurt, Austria Paul Grünbacher Johannes Kepler University Linz, Linz, Austria Andreas Günter HITeC e.V., University of Hamburg, Hamburg, Germany Albert Haag SAP AG, Walldorf, Germany Alois Haselböck Siemens AG, Vienna, Austria Mikko Heiskala Aalto University, Aalto, Finland Harald Hofbauer Kapsch Carrier Com, Vienna, Austria Lothar Hotz HITeC e.V., University of Hamburg, Hamburg, Germany Björn Höfling encoway, Bremen, Germany

xvii

xviii

List of Contributors

Dietmar Jannach Dortmund University of Technology, Dortmund, Germany Michael Jeran Graz University of Technology, Graz, Austria Thorsten Krebs encoway GmBH, Bremen, Germany Martin Lehofer Siemens VAI Metals Technologies, Linz, Austria Gerhard Leitner Alpen-Adria Universität Klagenfurt, Klagenfurt, Austria Monika Mandl Graz University of Technology, Graz, Austria Wolfgang Mayer University of South Australia, Adelaide, SA, Australia Tomi Männistö Aalto University, Aalto, Finland Iulia Nica Graz University of Technology, Graz, Austria Gerald Ninaus Graz University of Technology, Graz, Austria Roland Ochenbauer Kapsch Business Com, Vienna, Austria Klas Orsvärn Tacton, Stockholm, Sweden Frank T. Piller RWTH Aachen, Aachen, Germany Rick Rabiser Johannes Kepler University Linz, Linz, Austria Florian Reinfrank Graz University of Technology, Graz, Austria Stefan Reiterer SelectionArts, Graz, Austria Anna Ryabokon Alpen-Adria Universität Klagenfurt, Klagenfurt, Austria

List of Contributors

Gottfried Schenner Siemens AG, Vienna, Austria Christian Schober Kapsch Business Com, Vienna, Austria Herwig Schreiner Siemens AG Österreich, Vienna, Austria Markus Stumptner University of South Australia, Adelaide, SA, Australia Erich Teppan Alpen-Adria Universität Klagenfurt, Klagenfurt, Austria Juha Tiihonen Aalto University, Aalto, Finland Michael Vierhauser Siemens VAI Metals Technologies, Linz, Austria Katharina Wolter HITeC e.V., University of Hamburg, Hamburg, Germany Lois Wortley Oracle Corporation, Burlington, MA, USA Franz Wotawa Graz University of Technology, Graz, Austria Markus Zanker Alpen-Adria Universität Klagenfurt, Klagenfurt, Austria

xix

This page is intentionally left blank

Foreword Industrialization brought us the ability to efficiently produce the same products. However, some types of businesses are not well served by delivering the same product to all customers. Manufacturers try to address this problem by creating a fixed set of product variants that contain a predefined set of options in the hope that one of these variants might suit customer needs. Unfortunately, for highly variant products, this strategy does not provide a suitably close match to satisfy individual customer needs. To allow for individual customization, configuration systems first were applied to complex industrial products such as trucks and high-end computer systems. International Harvester in the 1960s implemented in Assembly language one of the first computerized support systems for configuration of trucks. Digital Equipment Corporation (DEC) fielded the first rule-based configuration expert system R1 in 1978 and XCON in 1980 for ordering and configuring VAX computers, saving DEC millions of dollars each year. These systems were used by experienced sales people who helped to place an order for a customer. Broad acceptance of the Internet created a tremendous push for configuration systems. It opened up direct consumer access to configuration systems, making them applicable for highly variant consumer products. PC manufacturers were one of the first to jump on this bandwagon, offering custom ordering capabilities for their PCs via the Internet. Now we live in the age of mass customization where companies find value in providing customers with the ability to custom-tailor products while keeping the prices in line with the mass produced products. Configuration systems play a central role in the continuing trend of mass customization that affects an ever-increasing number of products. Bill Paseman, founder of Calico Commerce, an early pioneer startup in the configuration field, introduced me to what could be one of the best made cases for providing configuration systems: a diner scene from the movie ‘‘Five Easy Pieces,’’ where Jack Nicolson is trying to order a ‘‘customized’’ chicken-salad sandwich in a restaurant. You can easily find the scene on YouTube. It provides an entertaining example of a user experience without configuration capabilities. Configuration spans a broad spectrum of tasks from simple product options selection for a custom athletic shoe to configuring an airplane. After all, an airplane is just one million parts flying in close formation. All of us encounter configuration problems in one way or another in our lives. If you bought a car, you probably dealt with it at some level already, knowingly or unknowingly. Companies that implement configuration systems well provide great experiences for their customers while solving daunting tasks on the back end where technical and business logistics capabilities are integrated. For more complex products configuration requires technical innovation and extensive re-engineering of a company’s internal business processes. I discovered configuration problems in 1985, working at Xerox PARC, while still finishing research on my PhD thesis in Stanford’s AI Lab. Xerox had just entered the PC business and was selling them via a sales force accustomed to selling copiers. All PC options and some compatibility rules were captured on pieces of paper that were provided to the sales people. Forty percent of the orders that were placed had some sort of error that precluded delivering a working PC to a customer. Most expert configuration systems built at that time were rule-based. Unfortunately, large rule-based systems were fairly difficult to maintain since all knowledge was represented using production rules. We started to research a ‘‘better,’’ more maintainable technology for delivering configuration systems that would help with the Xerox PC ordering problem. The result was the development of the Cossack system, one of the early model-based configurators providing a separation between domain knowledge, problem

xxi

xxii

Foreword

solving knowledge, and user requirements. Cossack provided predefined types of component relations such as part-of, compatibility, required, and connectivity that were mapped into a dynamic constraint processing engine. This work culminated in a paper I co-authored with Sanjay Mittal that provided one of the first formalizations of the configuration task. Since then I have continued to work on configuration problems at HP Laboratories, where we researched mechanisms for delivering fast exhaustive solutions space exploration and construction of user interfaces that proactively precluded users from selecting incompatible options by utilizing highly optimized constraint propagation algorithms. In 1999 I joined Calico Commerce where we created a new configuration environment geared toward simpler configuration tasks supporting a large number of simultaneous users over the Internet. This system was based on stateless compiled processing architecture delivering over two orders of magnitude improvement in the speed of operation and the computing resources footprint. Most configuration systems have a sizable compute-intensive footprint and require maintaining a state of computation throughout the configuration session. Such systems could not be scaled easily to support a large number of simultaneous Internet users. We architected a new configuration environment that was targeting a class of simpler configuration problems by providing stateless bit-vector compiled constraints processing with more than two orders of magnitude improvement over the previous system in the speed of operation and similar reduction in the computing resources footprint. This system could not address more complex technical configuration tasks, but provided excellent performance on the target set of problems. At first glance, some configuration solutions could be seductively easy to implement, but for more complex problems, implementations may end up to be fairly difficult to execute well. In the process of implementation of various configuration systems I have discovered some very difficult and thorny underlying problems related to tight interconnection between system maintainability, user interface design, and response time that must be overcome. This book will help you understand these problems and provide you with various approaches on how to address them. A well-constructed configuration system must provide capabilities to create a maintainable knowledge base, deliver refined user experience, and offer fast exploration of an exponentially large solutions space with an acceptable computer resource footprint for the targeted user load. In this book you will find how real-world configuration applications and configuration environments address these requirements. This book is an excellent introduction and overview of the field of Configuration Systems. It covers the most important developments in the field. The book discusses implications of configuration on the overall company business processes in support of mass customization. It provides the reader with a working definition of configuration problems and defines a range of configuration tasks from simple selection to technical configuration. It puts configuration in the context of other related tasks such as design, planning, product data management, and so on, and lays out discussion and good comparisons of formal representations and reasoning mechanisms while addressing the issues related to the design of user interfaces. Advanced topics covered include personalization, automated test and debugging of configuration information, as well as discussion of open research issues. The book presents an in-depth review of configuration business cases in different application domains. It also provides a presentation of commercial and free configuration environments that could be used as a basis for implementing configuration systems for different application domains. This book will serve multiple audiences. For industry people this book provides an introduction to the field and an in-depth review of the latest developments, describes experiences with real world

Foreword

xxiii

applications, and provides insights into commercial benefits to enterprises. In addition, it gives references to open source tools, configuration environments, and resources that would be helpful in developing solutions for specific applications. The book is also well suited for an advanced course on configuration in Computer Sciences. Researchers and PhD students will find in the book a discussion of open issues for future research. This book is written by four main authors—Alexander Felfernig, Lothar Hotz, Claire Bagley, and Juha Tiihonen—all of them well-respected researchers in the field of configuration systems. Claire Bagley also possesses extensive practical experience in this field. In addition, there are many other authors who provide significant contributions to individual chapters of this book. The book serves as a definitive guide to the field of Configuration Systems. It offers a good historical perspective and provides an enlightening view of a fascinating field of endeavor that has a rich blend of academic research with a plethora of practical applications. The book is well researched and thorough, providing a great value as an exhaustive compendium of field references. I have worked on configuration problems in various applications several times in my career, and have returned to it from a somewhat unexpected angle. You may find configuration problems everywhere, if you keep your eyes open. This book will take you on the enticing journey of problems and solutions, teaching you techniques that you may find useful multiple times in your professional careers. Happy explorations. Felix Frayman

This page is intentionally left blank

PART

Introduction

1

This page is intentionally left blank

CHAPTER

Motivation for the Book

1

Alexander Felfernig* , Lothar Hotz† , Claire Bagley‡ , and Juha Tiihonen§ † HITeC

* Graz University of Technology, Graz, Austria e.V., University of Hamburg, Hamburg, Germany ‡ Oracle Corporation, Burlington, MA, USA § Aalto University, Aalto, Finland

Abstract: Welcome to this book on configuration systems! The purpose of this book is to expose the reader to a field of Artificial Intelligence that has been successfully integrated and used in the industry for more than 30 years. This book provides configuration-related material for interested readers from the fields of industry, education, and research.

1.1 What Is Configuration? This part of the book starts with a motivation, takes a look at historical developments (Chapter 2), related technological issues (Chapter 3), and commercial benefits (Chapter 4). Chapter 5 provides an overview of the organization of the book. Mass Production. In the first part of the last century, Henry Ford introduced the T model (see Figure 1.1) and revolutionized the way cars were manufactured by introducing the concept of mass production, which is the efficient production of a high number of identical products. One of the best characterizations of mass production was given by Ford himself: You can have any car color as long as it’s black (remark about T model in 1909). Mass Customization. In the meantime, the mass production of identical products is a business model of the past since buyer markets predominate. This situation imposes new challenges on production and sales processes since companies are now forced to provide products that meet the individual needs of their customers. As a consequence, the mass customization paradigm (Anderson and Pine, 1996; Pine, 1999) has been established. This paradigm is based on the idea of the customer-individual production of highly variant products under near mass production pricing conditions. This means that the major goal was not only to perform a paradigm shift to more intensively take into account customer requirements and preferences but also to achieve this goal under mass production level time and pricing conditions. The era of mass customization ringed the bell for technological developments urgently needed to effectively implement the paradigm. Configuration technologies have evolved into a leading technology to support mass customization business scenarios. Knowledge-based Configuration. One definition of configuration (as an activity) has been given by Sabin and Weigel (1998), who define configuration as “a special case of design activity where the Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00001-3 © 2014 Elsevier Inc. All rights reserved.

3

4

CHAPTER 1 Motivation for the Book

FIGURE 1.1 Sketch of Ford T-model produced around 1908.

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.” Component types are further characterized by attributes and represent sets of alternative components (instances); for example, a Motherboard can be either an MBSilver or an MBDiamond (see Figure 1.2); an attribute of a Motherboard is price. Components are related to each other via part–whole relationships (also denoted as aggregations, e.g., a CPU is part of a Motherboard) or generalization relationships (also denoted as taxonomies, e.g., MBSilver is a Motherboard). In Sabin and Weigel’s definition, configuration is typically knowledgebased (knowledge-based configuration) since it relies on product domain and problem-solving knowledge. Constraints are restricting the way in which different components can be combined with each other; for example, an MBSilver must not be combined with a CPUD. Component types and constraints are also known as configuration model. Configuration models are needed due to the fact that in many cases there is a huge number of possible configurations. If we would store each individual solution, for example, in a database, searching for the preferred solution would be an extremely time-consuming task (Falkner et al., 2011); in addition, maintaining the set of different solutions would also be extremely time-consuming. The process of developing a configuration model is known as knowledge acquisition process. In the case that a customer is interested in a personal computer, his/her requirements have to be taken into account; for example, the customer prefers to have a motherboard of type MBSilver. The union of a configuration model and a corresponding set of customer requirements is known as configuration task (Mittal and Frayman, 1989). The configuration task then is the input for a configuration system (configurator) that determines a configuration (see, e.g., Figure 1.3). A configuration environment can be seen as the union

1.1 What Is Configuration?

5

FIGURE 1.2 A simple example of a configuration model (personal computer – PC). PC configuration serves as a working example throughout the whole book. For a more detailed configuration model of a PC see Chapter 6.

FIGURE 1.3 A simple example of a personal computer configuration.

6

CHAPTER 1 Motivation for the Book

of a configurator and the associated knowledge acquisition and maintenance component. As may have been observed by the reader, the term configuration is overloaded since it represents both the process of generating an artifact, which is comprised of instances of component types, and the artifact itself, the outcome of a configuration process, which for example, can be a bill of material (BoM).

1.2 Why Use Configuration Technologies? A short answer to this question is that configuration technologies significantly reduce the development and maintenance costs of key functionalities needed for the implementation of the mass customization paradigm. These functionalities encompass the efficient development and maintenance of constraint sets (configuration knowledge bases), the development and maintenance of configurator user interfaces, and the integration of configurators into existing software environments such as ERP (Enterprise Resource Planning) systems and systems supporting product data management (PDM). For a more detailed discussion of the commercial benefits of configuration technologies, refer to Chapter 4 of this book. Persons involved in a configurator project (stakeholders). Persons responsible for the development of a configurator application (or parts of it) are denoted as knowledge engineers. Knowledge engineers have deep knowledge about configuration technologies and cooperate closely with domain experts who are the major providers of technical (product engineers), marketing, and sales knowledge (experts from marketing and sales). Knowledge acquisition is the process of transforming product domain knowledge into the formal representation of a configuration knowledge base (configuration model). In order to develop and maintain a configuration knowledge base that really reflects the real-world product domain, a number of communication iterations between domain experts and knowledge engineers are necessary. This can result in a communication overhead, which is also well known as the knowledge acquisition bottleneck. The third group of stakeholders involved in a configuration project are end users who are applying the configurator in the context of real-world business processes such as technical or sales configuration.

1.3 Why Read This Book? Configuration is one of the most successfully applied technologies of Artificial Intelligence (AI). It is applied in many different product and service domains such as automotive, telecommunication, electronic equipment, elevators, railways, and financial services. Major reasons for reading this book are the following. (1) For industry representatives not familiar with configuration technologies this book provides a detailed introduction into basic configuration technologies and includes a set of business cases that show successfully deployed configuration environments as well as cases of ongoing deployments. We want to point out that this book is not intended to serve as an introduction to a specific configuration system; however, we provide an overview of technologies used in commercial configuration environments. (2) For industry representatives who already have expertise in the application of configuration technologies this book includes a discussion of new technologies and approaches currently not integrated in configuration environments. To mention examples in this context, we show how recommendation technologies can be applied to improve the interaction with configuration systems, the impact that theories of human decision making have on the way customers will interact with configurator interfaces, and

References

7

how such systems can be tested have on the basis of an integrated approach to consistency-based knowledge base testing and (automated) debugging. (3) For representatives from industry and academia interested in teaching configuration technologies, we provide throughout the whole book working examples that are related to the product domain of personal computer configuration. We selected this domain due to the fact that it is well known and often used as a reference example. In addition, we provide a set of slides that can be used freely for courses on the topic of configuration systems.1 (4) For researchers interested in configuration systems we provide an overview of basic technologies as well as an introduction to advanced topics that finally lead to a discussion of issues for future research. A more in-depth overview of the contents of this book including recommendations for which parts are useful for which segments of readers can be found in Chapter 5.

References Anderson, D., Pine, B.J., 1996. Agile Product Development for Mass Customization. McGraw-Hill. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation Technologies for Configurable Products. AI Magazine 32 (3), 99–108. Mittal, S., Frayman, F., 1989. Towards a generic model of configuration tasks. In: 11th International Joint Conference on Artificial Intelligence (IJCAI-89), Detroit, Michigan, USA, vol. 2 pp. 1395–1401. Pine, B.J., 1999. Mass Customization: The New Frontier in Business Competition. Harvard Business School Press. Sabin, D., Weigel, R., 1998. Product configuration frameworks – a survey. IEEE Intelligent Systems 13 (4), 42–49.

1 See

www.configurationbook.org.

This page is intentionally left blank

CHAPTER

A Short History of Configuration Technologies

2

Lothar Hotz* , Alexander Felfernig† , Andreas Günter* , and Juha Tiihonen‡ * HITeC

e.V., University of Hamburg, Hamburg, Germany † Graz University of Technology, Graz, Austria ‡ Aalto University, Aalto, Finland

Abstract: Nearly 40-years of configuration technologies motivated us to give this brief overview of the main configuration technological streams. We outline the technological developments in the field starting from the first expert systems of the late 1970s down to today’s configuration solutions. The vastness and intricacies of the configuration field makes it impossible to cover concisely all of its relevant aspects. For the purpose of this overview, we decided to focus on the following four different yet overlapping technological developments: (1) rule-based configurators, (2) early model-based configurators, (3) mainstream configuration environments, and (4) mass customization toolkits.

2.1 Rule-based Configurators Weak Artificial Intelligence (Weak AI) (Searle, 1980) denotes an interpretation of AI in the narrow sense: it supports the accomplishment of specific problem-solving tasks (such as configuration), not encompassing the full range of human cognitive abilities (see Russel and Norvig, 2003). In the line of weak AI (the term was not known at that time), many expert systems were developed in the 1970s. Examples of successful configuration expert systems are (1) R1/XCON (a first version was developed in the late 1970s), a computer configurator (Bachant and McDermott, 1984; McDermott, 1982; Soloway et al., 1987) and (2) VT (vertical transportation), a system for handling the design of elevator systems at the Westinghouse Elevator Company (Marcus et al., 1987). One of the major reasons for applying expert system technologies was the failure of procedural (e.g., FORTRAN-based) approaches to solve the configuration problem. As an example, we focus on the R1/XCON configurator. R1/XCON was an expert system initially implemented by John McDermott on the basis of OPS5 (Forgy, 1981); that is production rules were used for expressing configuration knowledge (see, e.g., Figure 2.1). R1/XCON was developed to support order generation for VAX computer systems (initially for Digital Equipment VAX-11 systems, later for PDP, MICROVAX, and MICRO-PDP). Before R1/XCON was introduced, computers at Digital Equipment (DEC) were configured manually. As a consequence, sales personnel created erroneous, incomplete, and infeasible configurations, which caused enormous overheads and costs. The overall net return to DEC was estimated $40 million dollars per year as the result of the successful delivery of valid and completely configured systems. Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00002-5 © 2014 Elsevier Inc. All rights reserved.

9

10

CHAPTER 2 A Short History of Configuration Technologies

ASSIGN-POWER-SUPPLY-1 IF:THE AND AND AND AND AND

MOST CURRENT ACTIVE CONTEXT IS ASSIGNING A POWERSUPPLY AN SBIMODULE OF ANY TYPE HAS BEEN PUT IN A CABINET THE POSITION IT OCCUPIES IN THE CABINET IS KNOWN THERE IS SPACE IN THE CABINET FOR A POWER SUPPLY THERE IS NO AVAILABLE POWER SUPPLY THE VOLTAGE AND FREQUENCY OF THE COMPONENTS IS KNOWN

THEN: FIND A POWER SUPPLY OF THAT VOLTAGE AND FREQUENCY AND ADD IT TO THE ORDER

FIGURE 2.1 A typical rule (paraphrased) in R1/XCON (McDermott, 1982). The condition part describes the current configuration context (configuration) and the action part includes actions to extend this configuration.

Although very successful, R1/XCON had a major drawback: the chosen knowledge representation. The rule-based implementation triggered enormous efforts in knowledge base development and maintenance (Soloway et al., 1987). An example of a rule defined in the R1/XCON system is given in Figure 2.1. The main problem of R1/XCON was the dependency between domain and problem solving knowledge; that is when domain knowledge had to be adapted, this caused changes in the problem solving knowledge and vice versa (Bachant and McDermott, 1984; Soloway et al., 1987). In other words, the outcome of the configuration process strongly depended on the ordering in which different rules were interpreted. To achieve a certain outcome (configuration), obscure ‘tricks’ were applied to enforce a certain sequence of rule firing (Soloway et al., 1987). This unfortunate situation motivated new technological developments that can be summarized with the term model-based knowledge representations.1

2.2 Early Model-based Configurators The major characteristic of model-based configuration is a clear separation between domain knowledge and problem solving knowledge. In the configuration context, this is realized by a separation of productspecific knowledge and knowledge related to configuration search; that is finding consistent solutions. Constraint satisfaction problems (CSPs) (see Hotz et al., 20142 ) are a widely used model-based knowledge representation formalism. Early versions of CSPs were already developed in the late 1970s (Lauriere, 1978; Mackworth, 1977). Multidirectionality can be considered the main difference between rule-based and constraint-based problem solving. In contrast to constraint-based representations, rules are based on if-then structures, and their interpretation presupposes a direction from the condition to the action part. Restrictions formulated as constraints make it possible to assign a value to an arbitrary variable. A constraint solver can propagate 1 Note that rule-based systems are still successfully applied (predominantly in product domains of limited size and complexity). 2 Chapter

6.

2.3 Mainstream Configuration Environments

11

consequences of assignments to other variables and the order of variable assignments does not affect constraints. Nowadays, basic constraint technologies are provided by open source constraint libraries such as CHOCO,3 JACOP,4 and MINION.5 A major characteristic of many configuration domains is the need of component-oriented configuration knowledge representations (Mittal and Frayman, 1989). In order to assure the maintainability of the configuration model, component types and their relationships are treated as first class entities within an object model; that is component types and relationships are not represented as variables and constraints but as component types and generic constraints (see Hotz et al., 2014). Without any claim to completeness, we want to mention the following “early” environments that supported a component-oriented knowledge representation: COSSACK (Frayman and Mittal, 1987), (Wright et al., 1993), COCOS (Stumptner et al., 1994), Beologic (Skovgaard, 1996), Trilogy (Franke, 1996),6 Selectica,7 Caméléon (Aldanondo et al., 2000),8 SAP9 (Haag, 1996), and further developments of the PLAKON configurator (Cunis et al., 1991; Günter and Cunis, 1992; Neumann, 1988; see also Haag, 201410 ).

2.3 Mainstream Configuration Environments Today, component-oriented technologies are widely used for the representation and solving of configuration tasks. Promising results with the early systems and a cut in prices by several orders of magnitude due to the transition from classic AI environments to mainstream environments triggered further developments (and also redevelopments), which ended in industrial-strength configuration environments such as Tacton (Orsvärn and Axling, 1999), ConfigIT (Moeller et al., 2001), EngCon (further development of KONWERK; see Hotz and Günter, 201411 ; Ranze et al., 2002), and ILOG; see Junker and Mailharro, 2003; Mailharro, 199812 . At the same time, configuration environments were increasingly integrated into ERP (enterprise resource planning) solutions; examples are SAP (Haag, 1998), BAAN (Yu and Skovgaard, 1998), and ORACLE.13 ERP systems and supply chain integration made configuration a mainstream technology simply due to the fact that ERP systems were already widely used. Complex configuration tasks need generative configuration approaches; this is the generation of components (instances of component types) and corresponding constraints (instances of generic constraints) on demand. This capability is a further development of early component-oriented configuration approaches. Component-oriented knowledge representations and generative problem solving are crucial for complex domains such as telecommunication (Fleischanderl et al., 1998; Stumptner et al., 1998, 3 www.emn.fr

4 www.osolpro.com

5 minion.sourceforge.net 6 www.trilogy.com

7 www.selectica.com

8 www.cameleon-software.com 9 www.sap.com

10 Chapter

27. 24. 12 Now: www.ibm.com 13 www.oracle.com 11 Chapter

12

CHAPTER 2 A Short History of Configuration Technologies

FIGURE 2.2 Siemens railway interlocking hardware.

FIGURE 2.3 Example of gear drives that are parts of drive control systems arranged and dimensioned by the DSD (Drive Solution Designer) configurator. DSD is implemented with the configuration tool EngCon (see Krebs, 2014, Chapter 23). Such drives are used for printing and sorting machines or automated saws. The variability in these domains stems from a large number (thousands) of different engines, gears, controllers, and other components and their variants.

2.4 Mass Customization Toolkits

13

1994), railway interlocking (see Falkner and Schreiner, 201414 ), cabin-layouts (Kopisch and Günter, 1992), the automotive industry (Pargamin, 2002), and drive systems (Ranze et al., 2002). Most of these configuration environments do support generative problem solving. A screenshot of railway interlocking hardware is depicted in Figure 2.2; drive systems are shown in Figure 2.3. The increasing size and complexity of configuration models (and corresponding configurations) triggered the development of further technologies. Approaches such as binary decision diagrams (BDDs; Andersen et al., 2010) and solution automata (Amilhastre et al., 2002) allow efficient reasoning especially in nongenerative configuration settings. Diagnosis and repair algorithms help users to overcome inconsistent situations (Felfernig et al., 2012; Junker, 2004; Sinz et al., 2007) in an efficient fashion (Card et al., 1991). Increasing model complexity triggered the development of graphical development and test environments that helped to increase understandability and maintainability of configuration knowledge bases (Aldanondo et al., 2000; Felfernig, 2007; Felfernig et al., 2004, 2000, 2013b; Haug, 2010). Today’s commercial environments provide graphical notations that allow the formulation of partonomies, taxonomies, and related constraints (sometimes also denoted as business rules). In addition to constraint-based approaches, Answer Set Programming (ASP) became a paradigm for configuration knowledge representation (Aschinger et al., 2012; Friedrich et al., 2011; Myllärniemi et al., 2005; Simons et al., 2002; Soininen et al., 2001; Tiihonen et al., 2003, 2013). ASP maps a logicbased configuration model onto propositional logic theories and solves them with SAT-solvers (see Hotz et al., 2014).15 Due to a first order logic-based knowledge representation, ASP allows a componentoriented representation of configuration tasks, and thus is a potential alternative to constraint-based approaches. The configuration system WeCoTin (Tiihonen et al., 2013) was implemented on the basis of this technology and tested against several application domains. The commercial version of WeCoTin is VariSales—(see Tiihonen and Anderson, 2014).16

2.4 Mass Customization Toolkits The goal of mass customization is to efficiently provide customers with what they want, when they want it, and at a competitive price (see Piller and Blazek, 2014).17 This widespread business requirement triggered the demand for technologies that intelligently support customers (end users) in autonomously configuring (codesign) products and services that fit their wishes and needs. Configurators deployed in such application scenarios are often referred to as mass customization toolkits (Aldanondo and Vareilles, 2008; Franke and Piller, 2003). Enabling customers to configure products and services on their own triggered the development of personalization technologies that provide services such as the automated recommendation of parameter values, whole (sub-) configurations, and questions of interest for the user (Ardissono et al., 2003; Chevaleyre et al., 2007; Cöster et al., 2002; Domshlak et al., 2000; Falkner et al., 2011; Felfernig and Burke, 2008; Felfernig et al., 2013a; Stegmann et al., 2003; Tiihonen and Felfernig, 2010). Furthermore, configurators were enabled to recommend alternative parameter settings in situations where no solution 14 Chapter

16. 6. 16 Chapter 26. 17 Chapter 9. 15 Chapter

14

CHAPTER 2 A Short History of Configuration Technologies

could be found for the given set of customer requirements (Felfernig et al., 2009, 2012; Junker, 2004; Sinz et al., 2007). For an overview of the application of recommendation technologies in configuration scenarios refer to Tiihonen et al. (2014).18 An example of a mass customization toolkit is mi adidas,19 which supports the configuration of individualized shoes (see also Piller and Blazek, 2014). Besides supporting customers in finding products and services that fit their wishes and needs, mass customization toolkits are also exploited for the identification of new requirements emerging in the customer community. On the one hand, such requirements can be derived by analyzing customer interactions with the mass customization toolkit, and on the other hand, customers themselves can be integrated into a company’s new product development processes. Both of these approaches exploiting customer knowledge for new product development are related to the concept of open innovation (Chesbrough, 2003); that is to systematically integrate customers into a company’s value chain. A nice example of an open innovation toolkit is introduced by Piller et al. (2004), who present a community-based environment for the cooperative development of computer games. In this context, an open innovation toolkit supports the generation of new game components without the need of programming knowledge.

2.5 Conclusion In this chapter, we provided an outline of configuration-related historical developments. These developments can be briefly characterized as follows: • • • •

From initial applications as rule-based expert systems, Via early model-based configurators, which allow a clear separation of domain knowledge and problem-solving knowledge, To mainstream model-based configuration environments integrated in supply chains and ERP systems, And mass customization toolkits.

The history of configuration reflects many different developments that ultimately lead to industrial strength configuration technologies. As such, configuration can be seen as one of the most successful application areas of Artificial Intelligence technologies. We are aware of the fact that not all configuration-related developments could be considered in this chapter, and refer you to further related work, for example, on resource-based configuration (Heinrich and Jüngst, 1991; Jüngst and Heinrich, 1998), functional approaches (Stein, 1995), description logicbased configuration (McGuinness and Wright, 1998; Wright et al., 1993), hybrid configuration (Günter, 1995; Hotz, 2009; Junker and Mailharro, 2003; McGuinness and Wright, 1998; Wright et al., 1993), and related topics that are discussed in Chapter 3. For further historical remarks, refer to overviews such as Forza and Salvador (2002), Günter and Kühn (1999), Jannach et al. (2007), Sabin and Weigel (1998), Soininen et al. (1998), and Stumptner (1997).

18 Chapter

13.

19 www.miadidas.de

References

15

References Aldanondo, M., Vareilles, E., 2008. Configuration for mass customization: how to extend product configuration towards requirements and process configuration. Journal of Intelligent Manufacturing 19 (5), 521–535. Aldanondo, M., Rouge, S., Veron, M., 2000. Expert configurator for concurrent engineering: Caméléon software and model. Journal of Intelligent Manufacturing 11 (2), 127–134. Amilhastre, J., Fargier, H., Marquis, P., 2002. Consistency restoration and explanations in dynamic CSPs – application to configuration. Artificial Intelligence 135 (1–2), 199–234. Andersen, H., Hadzic, T., Pisinger, D., 2010. Interactive cost configuration over decision diagrams. Journal of Articial Intelligence Research 37, 99–139. Ardissono, L., Felfernig, A., Friedrich, G., Goy, A., Jannach, D., Petrone, G., Schäfer, R., Zanker, M., 2003. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine 24 (3), 93–108. Aschinger, M., Drescher, C., Vollmer, H., 2012. LoCo – a logic for configuration problems. In: 20th European Conference on Artificial Intelligence (ECAI2012). IOS Press, Montpellier, France, pp. 73–78. Bachant, J., McDermott, J., 1984. R1 revisited: four years in the trenches. AI Magazine 5 (3), 21–32. Card, S., Robertson, G., Mackinlay, J., 1991. The information visualizer, an information workspace. In: CHI ’91 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, New Orleans, Louisiana, pp. 181–188. Chesbrough, H., 2003. Open Innovation. The New Imperative for Creating and Profiting from Technology. Harvard Business School Press, Boston. Chevaleyre, Y., Endriss, U., Lang, J., Maudet, N., 2007. A short introduction to computational social choice. In: 33rd Conference on Current Trends in Theory and Practice of Computer Science (SOFSEM-2007). Lecture Notes in Computer Science, vol. 4362. Springer, Harrachov, Czech Republic, pp. 51–69. Cöster, C., Gustavsson, A., Olsson, R., Rudström, A., 2002. Enhancing web-based configuration with recommendations and cluster-based help. In: Francesco, R., Barry, S. (Eds.), AH’02 Workshop on Recommendation and Personalized in e-Commerce. Universidad de Málaga, Málaga, Spain, pp. 30–40. Cunis, R., Günter, A., Strecker, H. (Eds.), 1991. The PLAKON-Book. Informatik-Fachberichte, vol. 266. Springer (in German: Das PLAKON-Buch). Domshlak, C., Genaim, S., Brafman, R., 2000. Preference-based configuration of web page content. In: 14th European Conference on Artificial Intelligence (ECAI 2000), Configuration Workshop, Berlin, Germany, pp. 19–22 (August 21–22). Falkner, A., Schreiner, H., 2014. SIEMENS: configuration and reconfiguration in industry. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 199–210 (Chapter 16). Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Felfernig, A., 2007. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management 54 (1), 41–56. Felfernig, A., Burke, R., 2008. Constraint-based recommender systems: technologies and research issues. In: ACM International Conference on Electronic Commerce (ICEC08), Innsbruck, Austria, pp. 17–26. Felfernig, A., Friedrich, G.E., Jannach, D., 2000. UML as domain specific language for the construction of knowledge-based configuration systems. International Journal of Software Engineering and Knowledge Engineering 10 (4), 449–469. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., 2004. Consistency-based diagnosis of configuration knowledge bases. Artificial Intelligence 152 (2), 213–234.

16

CHAPTER 2 A Short History of Configuration Technologies

Felfernig, A., Schubert, M., Friedrich, G., Mandl, M., Mairitsch, M., Teppan, E., 2009. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA, pp. 791–796. Felfernig, A., Schubert, M., Zehentner, C., 2012. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 26 (1), 53–62. Felfernig, A., Jeran, M., Ninaus, G., Reinfrank, F., Reiterer, S., 2013a. Toward the next generation of recommender systems: applications and research challenges. In: Tsihrintzis, G.A., Virvou, M., Jain, L.C. (Eds.), Multimedia Services in Intelligent Environments – Advances in Recommender Systems. Smart Innovation. Systems and Technologies, vol. 24. Springer, Heidelberg, New York, Dordrecht, London, pp. 81–98. Felfernig, A., Reiterer, S., Stettinger, M., Reinfrank, F., Jeran, M., Ninaus, G., 2013b. Recommender systems for configuration knowledge engineering. In: Workshop on Configuration, Vienna, Austria, pp. 51–54. Fleischanderl, G., Friedrich, G.E., Haselböck, A., Schreiner, H., Stumptner, M., 1998. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems 13 (4), 59–68. Forgy, C., 1981. OPS5 User’s Manual. Tech. Rep. Technical Report CMU-CS-81-135, Computer Science Department, paper 2397, Carnegie Mellon University. Forza, C., Salvador, F., 2002. Managing for variety in the order acquisition and fulfillment process: the contribution of product configuration systems. International Journal of Production Economics 76 (1), 87–98. Franke, D., 1996. Trilogy configurator – position statement. In: 13th National Conference on Artificial Intelligence (AAAI-96), Workshop on Configuration, No. AAAI FS-96-03, Portland, Oregon, pp. 148–149. Franke, N., Piller, F.T., 2003. Key research issues in user interaction with configuration toolkits in a mass customization system. The International Journal of Technology Management 26 (5–6), 578–599. Frayman, F., Mittal, S., 1987. COSSACK: a constraint-based expert system for configuration tasks. In: Sriram, D., Adey, R. (Eds.), Knowledge Based Expert Systems in Engineering: Planning and Design. Computational Mechanics Publications, Woburn, MA, pp. 143–166. Friedrich, G., Ryabokon, A., Falkner, A.A., Haselböck, A., Schenner, G., Schreiner, H., 2011. (Re)configuration based on model generation. In: Second Workshop on Logics for Component Configuration (LoCoCo 2011), Perugia, Italy, pp. 26–35. Günter, A., 1995. Knowledge-based Configuration. Infix, St. Augustin (in German: Wissensbasiertes Konfigurieren). Günter, A., Cunis, R., 1992. Flexible control in expert systems for construction tasks. Journal of Applied Intelligence 2 (4), 369–385. Günter, A., Kühn, C., 1999. Knowledge-based configuration – survey and future directions. In: Puppe, F. (Ed.), XPS-99: Knowledge Based Systems, Proceedings of the 5th Biannual German Conference on Knowledge Based Systems. Lecture Notes in Artificial Intelligence, vol. 1570. Springer, Würzburg. Haag, A., 1996. SAP configurator – position statement. In: 13th National Conference on Artificial Intelligence (AAAI-96), Workshop on Configuration, No. AAAI FS-96-03, Portland, Oregon, pp. 150. Haag, A., 1998. Sales configuration in business processes. IEEE Intelligent Systems 13 (4), 78–85. Haag, A., 2014. Product configuration in SAP – a retrospective. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 319–337 (Chapter 27). Haug, A., 2010. A software system to support the development and maintenance of complex product configurators. International Journal of Advanced Manufacturing Technology 49 (1–4), 393–406. Heinrich, M., Jüngst, E., 1991. A resource-based paradigm for the configuring of technical systems from modular components. In: 7th IEEE Conference on Artificial Intelligence for Applications (CAIA-91), Miami Beach, Florida, pp. 257–264 (February 24–28).

References

17

Hotz, L., 2009. Frame-based Knowledge Representation for Configuration, Analysis, and Diagnoses of Technical Systems. Dissertation, University of Hamburg, Germany (in German: Frame-basierte Wissensrepräsentation für Konfigurierung, Analyse und Diagnose technischer Systems). Hotz, L., Günter, A., 2014. KONWERK. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledgebased Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 281–295 (Chapter 24). Hotz, L., Felfernig, A., Stumptner, M., Ryabokon, A., Bagley, C., Wolter, K., 2014. Configuration knowledge representation and reasoning. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledgebased Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 41–72 (Chapter 6). Jannach, D., Felfernig, A., Kreutler, G., Zanker, M., Friedrich, G., 2007. Research issues in knowledge-based configuration. In: Mass Customization Information Systems in Business. Idea Group, pp. 221–236 (Chapter 11). Jüngst, W., Heinrich, M., 1998. Using resource balancing to configure modular systems. IEEE Intelligent Systems 13 (4), 50–58. Junker, U., 2004. QUICKXPLAIN: preferred explanations and relaxations for over-constrained problems. In: McGuinness, D.L., Ferguson, G. (Eds.), 19th International Conference on Artifical Intelligence (AAAI’04). AAAI Press, pp. 167–172. Junker, U., Mailharro, D., 2003. The logic of ILOG (J)configurator: combining constraint programming with a description logic. In: 18th International Joint Conference on Artificial Intelligence (IJCAI-03). Configuration Workshop, Acapulco, Mexico, pp. 13–20. Kopisch, M., Günter, A., 1992. Configuration of a passenger aircraft cabin based on conceptual hierarchy, constraints and flexible control. In: Belli, F., Radermacher, F. (Eds.), Industrial and Engineering Applications of Artificial Intelligence and Expert Systems (IEA/AIE-92). Lecture Notes in Computer Science, vol. 604. Springer, Paderborn, pp. 421–430. Krebs, T., 2014. encoway. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 271–279 (Chapter 23). Lauriere, J., 1978. A language and a program for stating and solving combinatorial problems. Artificial Intelligence 10 (1), 29–127. Mackworth, A., 1977. Consistency in networks of relations. Artificial Intelligence 8 (1), 99–118. Mailharro, D., 1998. A classification and constraint-based framework for configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (04), 383–397. Marcus, S., Stout, J., McDermott, J., 1987. VT: an expert elevator designer that uses knowledge-based backtracking. AI Magazine 8 (4), 41–58. McDermott, J., 1982. R1: a rule-based configurer of computer systems. Artificial Intelligence 19 (1), 39–88. McGuinness, D., Wright, J., 1998. An industrial-strength description logic-based configurator platform. Intelligent Systems and their Applications, IEEE 13 (4), 69–77. Mittal, S., Frayman, F., 1989. Towards a generic model of configuration tasks. 11th International Joint Conference on Artificial Intelligence (IJCAI-89), Detroit, Michigan, vol. 2 pp. 1395–1401. Moeller, J., Andersen, H., Hulgaard, H., 2001. Product configuration over the internet. In: 6th INFORMS Conference on Information Systems and Technology, Miami Beach, Florida,. Myllärniemi, V., Asikainen, T., Männistö, T., Soininen, T., 2005. Kumbang configurator – a configuration tool for software product families. In: 19th International Joint Conference on Artificial Intelligence (IJCAI-05). Configuration Workshop, Edinburgh, Scotland, UK, pp. 51–56. Neumann, B., 1988. Configuration expert systems: a case study and tutorial. In: Bunke, H.O. (Ed.), Proceedings of the 1988 SGAICO Conference on Artificial Intelligence in Manufacturing, Assembly, and Robotics, Oldenbourg, Munich, pp. 27–68.

18

CHAPTER 2 A Short History of Configuration Technologies

Orsvärn, K., Axling, T., 1999. The Tacton view of configuration tasks and engines. In: AAAI’99 Workshop on Configuration, Orlando, Florida, pp. 127–130. Pargamin, P., 2002. Vehicle sales configuration: the cluster tree approach. In: ECAI 2002 Workshop on Configuration, Lyon, France, pp. 35–40. Piller, F.T., Blazek, P., 2014. Core capabilities of sustainable mass customization. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 107–120 (Chapter 9). Piller, F.T., Ihl, C., Füller, J., Stotko, C., 2004. Toolkits for open innovation – the case of mobile phone games. In: 37th Hawaii International Conference on System Sciences, pp. 1–10. Ranze, K., Scholz, T., Wagner, T., Günter, A., Herzog, O., Hollmann, O., Schlieder, C., Arlt, V., 2002. A structure-based configuration tool: drive solution designer – DSD. In: 14th Conference on Innovative Applications of AI (IAAI-02), Edmonton, Alberta, Canada, pp. 845–852. Russel, S., Norvig, P., 2003. Artificial Intelligence – A Modern Approach, second ed. Prentice Hall, Upper Saddle River, NJ. Sabin, D., Weigel, R., 1998. Product configuration frameworks – a survey. IEEE Intelligent Systems 13 (4), 42–49. Searle, J., 1980. Minds, brains and programs. Behavioral and Brain Sciences 3 (3), 417–457. Simons, P., Niemelä, I., Soininen, T., 2002. Extending and implementing the stable model semantics. Artificial Intelligence 138 (1–2), 181–234. Sinz, C., Haag, A., Narodytska, N., Walsh, T., Gelle, E., Sabin, M., Junker, U., O’Sullivan, B., Rabiser, R., Dhungana, D., Grünbacher, P., Lehner, K., Federspiel, C., Naus, D., 2007. Configuration. IEEE Intelligent Systems 22 (1), 78–90. Skovgaard, H., 1996. salesPLUS a product configuration tool. In: 13th National Conference on Artificial Intelligence (AAAI-96), Workshop on Configuration. No. AAAI FS-96-03, Portland, Oregon, pp. 61–68. Soininen, T., Tiihonen, J., Männistö, T., Sulonen, R., 1998. Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (4), 357–372. Soininen, T., Niemelä, I., Tiihonen, J., Sulonen, R., 2001. Representing configuration knowledge with weight constraint rules. In: Provetti, A., Son, T.C. (Eds.), First International Workshop on Answer Set Programming: Towards Efficient and Scalable Knowledge (AAAI Technical Report SS-01-01), pp. 195–201. Soloway, E., Bachant, J., Jensen, K., 1987. Assessing the maintainability of XCON-in-RIME: coping with the problem of very large rule-bases. In: Proceedings of the Sixth National Conference on Artificial Intelligence (AAAI-87), Seattle, Washington, pp. 824–829 (July 13–17). Stegmann, R., Koch, M., Lacher, M., Leckner, T., Renneberg, V., 2003. Generating personalized recommendations in a model-based product configurator system. In: IJCAI 2003 Workshop on Configuration, Acapulco, Mexico, pp. 51–55. Stein, B., 1995. Functional Models in Configuration Systems. Dissertation, Universität Paderborn, Department of Mathematics and Computer Science. Stumptner, M., 1997. An overview of knowledge-based configuration. AI Communications 10 (2), 111–126. Stumptner, M., Haselböck, A., Friedrich, G., 1994. COCOS – a tool for constraint-based, dynamic configuration. In: 10th IEEE Conference on Artificial Intelligence for Applications (CAIA-94), San Antonio, TX, pp. 373–380. Stumptner, M., Friedrich, G., Haselböck, A., 1998. Generative constraint-based configuration of large technical systems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (4), 307–320. Tiihonen, J., Anderson, A., 2014. VariSales. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 309–318 (Chapter 26). Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406.

References

19

Tiihonen, J., Soininen, T., Niemelä, I., Sulonen, R., 2003. 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, p. 10 (Paper number: 1290). Tiihonen, J., Heiskala, M., Anderson, A., Soininen, T., 2013. WeCoTin – a practical logic-based sales configurator. AI Communications 26 (1), 99–131. Tiihonen, J., Felfernig, A., Mandl, M., 2014. Personalized configuration. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 167–179 (Chapter 13). Wright, J.R., Weixelbaum, E.S., Vesonder, G.T., Brown, K.E., Palmer, S.R., Berman, J.I., Moore, H.H., 1993. A knowledge-based configurator that supports sales, engineering, and manufacturing at AT&T network systems. AI Magazine 14 (3), 69–80. Yu, B., Skovgaard, H., 1998. A configuration tool to increase product competitiveness. IEEE Intelligent Systems 13 (4), 34–41.

This page is intentionally left blank

CHAPTER

Configuration-Related Topics

3

Alexander Felfernig* , Lothar Hotz† , Juha Tiihonen§ , and Claire Bagley‡ † HITeC

* Graz University of Technology, Graz, Austria e.V., University of Hamburg, Hamburg, Germany § Aalto University, Aalto, Finland ‡ Oracle 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.

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). 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 design are 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).

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00003-7 © 2014 Elsevier Inc. All rights reserved.

21

22

CHAPTER 3 Configuration-Related Topics

FIGURE 3.1 Different types of design tasks: (1) designs are derived from a fixed set of component types and 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). inc denotes incompatibility constraints.

FIGURE 3.2 Representing a planning task as a configuration task.

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 similar1 with 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. 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). 1 See

also www.puk-workshop.de.

3.3 Recommender Systems

23

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 contentbased 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).

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

f1

f2

f3

f4

f5

f6

s1

1

0

3

2

0

4

s2

1

0

0

2

4

3

s3

2

3

0

1

4

0

s4

1

4

0

2

0

3

s5

1

0

0

2

0

0

24

CHAPTER 3 Configuration-Related Topics

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 f 1 and f 4 , the most similar sessions (the four nearest neighbors) are the sessions {s1 , s2 , s4 , s5 } and f 6 would be recommended as the next text feature to be specified by the user ( f 6 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).

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).

References

25

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 Biundo, S., Günter, A., Hertzberg, J., Schneeberger, J., Tank, W., 1993. Planning and configuration. In: Görz, G. (Ed.), Introduction in Artificial Intelligence. Addison-Wesley, Bonn, Paris, Reading, pp. 767–828. Brown, D., Chandrasekaran, B., 1989. Design Problem Solving – Knowledge Structures and Control Strategies. Research Notes in Artificial Intelligence Series. Pitman Publishing, London. Edelkamp, S., Schrödl, S., 2012. Heuristic Search – Theory and Applications. Academic Press, Waltham, MA. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Felfernig, A., Burke, R., 2008. Constraint-based recommender systems: technologies and research issues. In: ACM International Conference on Electronic Commerce (ICEC08), Innsbruck, Austria, pp. 17–26. Felfernig, A., Friedrich, G., Jannach, D., Zanker, M., 2006. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC) 11 (2), 11–34. 2 Product 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).

26

CHAPTER 3 Configuration-Related Topics

Felfernig, A., Friedrich, G., Schmidt-Thieme, L., 2007. Guest editors’ introduction: special issue on recommender systems. IEEE Intelligent Systems 22 (3), 18–21. Felfernig, A., Schubert, M., Friedrich, G., Mandl, M., Mairitsch, M., Teppan, E., 2009. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA, pp. 791–796. Felfernig, A., Jeran, M., Ninaus, G., Reinfrank, F., Reiterer, S., 2013. Toward the next generation of recommender systems: applications and research challenges. In: Tsihrintzis, G.A., Virvou, M., Jain, L.C. (Eds.), Multimedia Services in Intelligent Environments Advances in Recommender Systems. Smart Innovation, Systems and Technologies, vol. 24. Springer, pp. 81–98. Geyer, L., 2002. Configuring product families using design spaces. In: Integrated Design and Process Technology (IDPT-2002). Society for Design and Process Science, Pasadena, CA, pp. 9 (CD ROM). Görz, G., 1993. Introduction in Artificial Intelligence. Addison-Wesley. Günter, A., Kühn, C., 1999. 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. Lecture Notes in Artificial Intelligence, vol. 1570. Springer, Würzburg. Hotz, L., Vietze, T., 1995. Innovative configuration in technical domains. In: PuK-95 – 9. Workshop Planen und Konfigurieren. DFKI Saarbrücken, Kaiserslautern, Germany, pp. 59–68 (in German: Innovatives Konfigurieren in technischen Domänen). Hotz, L., Wolter, K., Krebs, T., Deelstra, S., Sinnema, M., Nijhuis, J., MacGregor, J., 2006. Configuration in Industrial Product Families – The ConIPF Methodology. IOS Press, Berlin. Jannach, D., Zanker, M., Felfernig, A., Friedrich, G., 2010. Recommender Systems: An Introduction. Cambridge University Press. Konstan, J., Miller, B., Maltz, D., Herlocker, J., Gordon, L., Riedl, J., 1997. Grouplens: applying collaborative filtering to usenet news full text. Communications of the ACM 40 (3), 77–87. Männistö, T., Sulonen, R., 1999. 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. Lecture Notes in Computer Science, vol. 1727. Springer, Versailles, France, pp. 12–23. Männistö, T., Soininen, T., Sulonen, R., 2001. Modeling configurable products and software product families. In: 17th International Joint Conference on Artificial Intelligence (IJCAI-2001). Workshop on Configuration, Seattle, Washington, pp. 64–70. McDermott, J., 1982. R1: a rule-based configurer of computer systems. Artificial Intelligence 19 (1), 39–88. Myllärniemi, V., Asikainen, T., Männistö, T., Soininen, T., 2005. Kumbang configurator – a configuration tool for software product families. In: 19th International Joint Conference on Artificial Intelligence (IJCAI-05). Configuration Workshop, Edinburgh, Scotland, UK, pp. 51–56. Pazzani, M., Billsus, D., 1997. Learning and revising user profiles: the identification of interesting websites. Machine Learning 27 (3), 313–331. Ricci, F., Rokach, L., Shapira, B., Kantor, P., 2011. Recommender Systems Handbook. Springer. Sabin, D., Weigel, R., 1998. Product Configuration Frameworks – A Survey. IEEE Intelligent Systems 13 (4), 42–49. Stumptner, M., 1997. An overview of knowledge-based configuration. AI Communications 10 (2), 111–126. Thiel, S., Ferber, S., Fischer, T., Hein, A., Schlick, M., 2001. 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, pp. 43–55. Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406. Tiihonen, J., Lehtonen, T., Soininen, T., Pulkkinen, A., Sulonen, R., Riitahuhta, A., 1998. Modelling configurable product families. In: Fourth WDK Workshop on Product Structuring, Delft, The Netherlands, pp. 29–50.

References

27

van der Hoek, A., Heimbigner, D., Wolf, L., 1995. Does configuration management research have a future? In: Software Configuration Management – ICSE SCM-4 and SCM-5 Workshops Selected Papers. Lecture Notes in Computer Science, vol. 1005. Springer, Seattle, Washington, USA, pp. 305–309. White, A., Halpern, M., 2009. A Look at the Differences and Interactions Among PDM, PLM and MDM. Technical Report G00169693, Gartner. Ylinen, K., Männistö, T., Soininen, T., 2002. Configuring software products with traditional methods – case Linux Familiar. In: 15th European Conference on Artificial Intelligence (ECAI 2002), Configuration Workshop, Lyon, France, pp. 5–10.

This page is intentionally left blank

CHAPTER

Benefits of Configuration Systems

4

Alexander Felfernig* , Claire Bagley† , Juha Tiihonen‡ , Lois Wortley† , and Lothar Hotz§ * Graz

University of Technology, Graz, Austria Corporation, Burlington, MA, USA ‡ Aalto University, Aalto, Finland § HITeC e.V., University of Hamburg, Hamburg, Germany † Oracle

Abstract: In this chapter, we summarize challenges related to the implementation of mass customization. In this context, we discuss benefits that result from a successful deployment and application of configuration technologies.

4.1 Introduction Configuration is a key technology for successfully implementing mass customization (see Piller and Blazek, 20141 ). In this chapter, we take a look at key challenges in the context of mass customization and consequent benefits when using configuration technologies to address these challenges. Configurators can act as key components for efficiently reducing the time to market of potentially large, complex, and customizable products. Table 4.1 summarizes the challenges and benefits detailed hereafter.

4.2 Challenges and Benefits Challenge 1: Avoiding Erroneous and Suboptimal Offers. The goal of offering highly variant (configurable) products requires sales representatives to invest more time to understand the product assortment. The result of being confronted with high variability are erroneous offers that are often not noticed before production (e.g., Heiskala et al., 2007). Even if an offer is correct it can be suboptimal, including additional services/costs that are not needed for fulfilling the wishes and needs of the customer. This situation can lead to a turnover of customers. Configuration technologies can tackle this challenge in several ways. They include constraint technologies that support automated feasibility checks of customer requirements. Such checks contribute to a significant reduction of errors in the recording of orders (Hvam et al., 2010). Fewer errors in the order recording phase result in less customer complaints and confusion, shorter lead times (Barker et al., 1989; Haug et al., 2011), and increased sales performance 1 Chapter

9.

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00004-9 © 2014 Elsevier Inc. All rights reserved.

29

30

CHAPTER 4 Benefits of Configuration Systems

Table 4.1 Mass Customization (MC) challenges and benefits of configuration technologies. MC Challenge

Benefits of Configurators

(1) Avoiding Erroneous and Suboptimal Offers

Less or Zero Errors Shorter Lead Times Increased Sales Lower Personnel Costs Stable Effort Estimation Higher-Value Products Stable Schedules Customer Self Service Preinformed Customers Corporate Memory Increased Sales Preference Knowledge Open Innovation Reliable Demand Prediction Decreased Time to Market Less Errors Efficient Development Efficient Maintenance

(2) Avoiding Mass Confusion

(3) Complexity Handling of Needs Elicitation

(4) Knowledge Integration

(5) Efficient Knowledge Management

(Hvam et al., 2010). For the same amount of successfully acquired customer orders, we can expect lower (personnel) costs due to lower cycle times (Barker et al., 1989). A high degree of correct offers makes effort estimations stable. Furthermore, increased variety can be offered because sales representatives are enabled to handle the complexity (Heiskala et al., 2007). Challenge 2: Avoiding Mass Confusion. Mass Confusion (Huffman and Kahn, 1998) is triggered by large and complex product assortments. It denotes the fact that customers (users) may be overwhelmed by the size and complexity of a product assortment and, as a consequence, are not able to make a decision. The related psychological effect is that the higher the amount of available options, the higher the cognitive effort to identify and compare potential alternatives, and the lower the probability of high-quality decisions (Felfernig et al., 2007, 2006, 2008; Piller et al., 2005). In this context, configurators can provide a search interface that helps to narrow down the number of relevant options. Personalization technologies support more efficient decision processes (Felfernig et al., 2006). Easier to use (personalized) interfaces can encourage customers to apply a configurator autonomously (customer self-service) and, as a consequence, customers are preinformed. Finally, configuration knowledge can act as a kind of corporate memory that can be exploited for the education of new sales representatives. In this context, there is a lower risk of losing sales knowledge and product knowledge becomes more standardized (Hvam et al., 2010). Challenge 3: Complexity Handling of Needs Elicitation. As mentioned in Challenge 2, configuration and personalization technologies are needed to efficiently support users when searching for (configuring)

4.2 Challenges and Benefits

31

a product. In this context, intelligent needs elicitation is an important issue. Without having a clear view of the preferences of a user, it is simply not possible to identify the most relevant configurations (Ardissono et al., 2003; Falkner et al., 2011; Tiihonen and Felfernig, 2010). When starting a configuration process, users typically do not know their preferences beforehand but construct them within the scope of the configuration session (see Mandl et al., 20142 ). This aspect has to be taken into account by intelligent configurator user interfaces. Interfaces that successfully support customers in finding a configuration that fits their wishes and needs are able to increase sales and also allow a deep understanding of customer preferences (see, e.g. Felfernig et al., 2006). If a customer enters a set of requirements for which no solution (configuration) can be identified, this information can be exploited as well: the requirements can be collected for open innovation processes; that is, processes that explicitly integrate customers into a company’s new product development (Felfernig et al., 2004b). Challenge 4: Knowledge Integration. Successful companies are continually streamlining their core information technology systems in order to remain competitive. Businesses are strengthening the communication and information shared with customers through investments, for example, in Customer Relationship Management (CRM) systems and focusing on the data and knowledge that flows into their supply chain. The management of customers and suppliers relies heavily on the management of product knowledge across the enterprise. From the front-end to the back-end operations, knowledge must flow seamlessly and be accessible across every facet of the enterprise. A key issue when dealing with complex products and services is that configuration technologies are deeply integrated into supply chains (Ardissono et al., 2003). On the basis of such an integration, companies that are able to leverage timely information from these processes are better able to anticipate and predict demand, ultimately allowing them to better influence day-to-day operations and events (see, e.g., Hugos, 2011). State-of-the-art configurators can be fully and seamlessly integrated into a larger system to decrease the time to market of any large, complex, and customizable product; simplify the configuration of such products; reduce order and processing errors; and, therefore, increase profitability. As such, configurators provide the foundation for an integrated configuration, pricing, and quotation (CPQ) solution (Dunne and Alvarez, 2011). Challenge 5: Efficient Knowledge Management. Central to the configurator implementation is the definition of the product (configuration) knowledge (Mittal and Frayman, 1989). This knowledge may exist in a variety of sources including product data management systems, spreadsheets, legacy enterprise and CRM systems, or even in the heads of soon-to-retire employees. Early in the implementation of a configuration model, a knowledge acquisition and data cleansing stage is required to centralize the product knowledge (including the corresponding product data), preferably into a single source of truth shared throughout the enterprise. Sharing of common data across the enterprise is critical to maintain order accuracy and reduce cycle times. A successful configuration tool relies on its ability to create maintainable configuration models (Felfernig et al., 2013; Haug, 2010; Haug and Hvam, 2007) that enable users to efficiently enter needs (DeSisto, 1997). Top-of-the-line configurators enable businesses to create and maintain large configuration models (with a large set of constraints and large related product models) rapidly by giving product specialists the flexibility to model complex products without programming expertise in a time-dependent fashion (Alvarez and Dutra, 2009). Once a product structure has been created and/or imported from a central product definition repository, configuration modelers can state the necessary product business 2 Chapter

14.

32

CHAPTER 4 Benefits of Configuration Systems

rules (constraints) and preferences that will ensure the validity of the product configurations while meeting the customer’s requirements. Effective configurators also support mechanisms for testing large and complex configuration knowledge bases, providing an environment that simulates user interactions with a configuration model, checking that the configurator produces the expected configurations, providing explanations in the case of inconsistencies (Felfernig et al., 2004a; 2006). Fulfilling these requirements, configuration environments are able to successfully tackle the knowledge acquisition bottleneck in terms of efficient development and maintenance processes.

4.3 Conclusion In this chapter, we provided an overview of major challenges related to the implementation of mass customization. For each of these challenges, we discussed application scenarios for configuration technologies and benefits related to the application of these technologies. With this overview of business benefits related to the application of configuration technologies, this chapter provides insights that are of particular relevance for persons with limited experience in the application of configuration technologies. Further details on the impacts of configuration technologies in industrial environments can be found in overview publications such as Barker et al. (1989), Forza and Salvador (2002), Haug et al. (2011), Heiskala et al. (2005, 2007), and Hvam et al. (2010).

References Alvarez, G., Dutra, L., 2009. Marketscope for Sales Configuration. Technical Report G00169350, Gartner. Ardissono, L., Felfernig, A., Friedrich, G., Goy, A., Jannach, D., Petrone, G., Schäfer, R., Zanker, M., 2003. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine 24 (3), 93–108. Barker, V., O’Connor, D., Bachant, J., Soloway, E., 1989. Expert systems for configuration at Digital: XCON and beyond. Communications of the ACM 32 (3), 298–318. DeSisto, R., 1997. Constraints Still Key for Product Configurator Deployments. Technical Report T-22-9419, Gartner. Dunne, M., Alvarez, G., 2011. MarketScope for Configuration, Price, Quote Application Suites. Technical Report G00212720, Gartner. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., 2004a. Consistency-based diagnosis of configuration knowledge bases. Artificial Intelligence 152 (2), 213–234. Felfernig, A., Russ, C., Wundara, M., 2004b. Toolkits supporting open innovation in E-government. In: Sixth International Conference on Enterprise Information Systems, (ICEIS2004) Porto, Ortugal, vol. IV, pp. 296–303.. Felfernig, A., Friedrich, G., Jannach, D., Zanker, M., 2006. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC) 11 (2), 11–34.

References

33

Felfernig, A., Friedrich, G., Gula, B., Hitz, M., Kruggel, T., Melcher, R., Riepan, D., Strauss, S., Teppan, E., Vitouch, O., 2007. Persuasive recommendation: exploring serial position effects in knowledge-based recommender systems. In: De Kort, Y., IJsselsteijn, W., Midden, C., Eggen, B., Fogg, B.J. (Eds.), Second International Conference of Persuasive Technology (Persuasive 2007). Lecture Notes in Computer Science, vol. 4744. Springer, Palo Alto, CA, pp. 283–294. Felfernig, A., Gula, B., Leitner, G., Maier, M., Melcher, R., Teppan, E., 2008. Persuasion in knowledge-based recommendation. In: Oinas-Kukkonen, H., Hasle, P.F.V., Harjumaa, M., Segerståhl, K., Øhrstrøm, P. (Eds.), Persuasive Technology, Third International Conference (Persuasive 2008). Lecture Notes in Computer Science, vol. 5033. Springer, Oulu, Finland, pp. 71–82. Felfernig, A., Reiterer, S., Stettinger, M., Reinfrank, F., Jeran, M., Ninaus, G., 2013. Recommender systems for configuration knowledge engineering. In: Workshop on Configuration. Vienna, Austria, pp. 51–54. Forza, C., Salvador, F., 2002. Managing for variety in the order acquisition and fulfillment process: the contribution of product configuration systems. International Journal of Production Economics 76 (1), 87–98. Haug, A., 2010. A software system to support the development and maintenance of complex product configurators. International Journal of Advanced Manufacturing Technology 49 (1–4), 393–406. Haug, A., Hvam, L., 2007. The modeling techniques of a documentation system that supports the development and maintenance of product configuration systems. International Journal of Mass Customization 2 (1–2), 1–18. Haug, A., Hvam, L., Mortensen, N.H., 2011. The impact of product configurators on lead times in engineering-oriented companies. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 25 (2), 197–206. Heiskala, M., Paloheimo, K., Tiihonen, J., 2005. Mass customization of services: benefits and challenges of configurable services. In: Frontiers of e-Business Research (FeBR 2005), Tampere, Finland, pp. 206–221. Heiskala, M., Paloheimo, K.-S., Tiihonen, J., 2007. Mass customization with configurable products and configurators: a review of benefits and challenges. In: Mass customization information systems in business, first ed. IGI Global, pp. 1–32 (Chapter 1). Huffman, C., Kahn, B., 1998. Variety for sale: mass customization or mass confusion. Journal of Retailing 74 (4), 491–513. Hugos, M., 2011. Essentials of Supply Chain Management, third ed. Wiley. Hvam, L., Haug, A., Mortensen, N., 2010. Assessment of benefits from product configuration systems. In: Hotz, L., Haselböck, A. (Eds.), 19th European Conference on Artificial Intelligence (ECAI 2010), Workshop on Configuration, Lisbon, Portugal, pp. 9–14. Mandl, M., Felfernig, A., Teppan, E., 2014. Consumer decision making and configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 181–190 (Chapter 14). Mittal, S., Frayman, F., 1989. Towards a generic model of configuration tasks. In: 11th International Joint Conference on Artificial Intelligence (IJCAI-89), vol 2, Detroit, Michigan, USA, pp. 1395–1401. Piller, F.T., Blazek, P., 2014. Core capabilities of sustainable mass customization. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledgebased Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 107–120 (Chapter 9). Piller, F.T., Schubert, P., Koch, M., Möeslein, K., 2005. Overcoming mass confusion: collaborative customer co-design in online communities. Journal of Computer-Mediated Communication 10 (4), 1–28. Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406.

This page is intentionally left blank

CHAPTER

5

Overview of the Book

Alexander Felfernig* , Lothar Hotz† , Juha Tiihonen‡ , and Claire Bagley§ † HITeC

* Graz University of Technology, Graz, Austria e.V., University of Hamburg, Hamburg, Germany ‡ Aalto University, Aalto, Finland § Oracle Corporation, Burlington, MA, USA

Abstract: For the different readers interested in this book, we provide a short introductory overview of the book. This overview helps to select appropriate chapters and to assure an efficient start.

The Introduction (Part 1) highlights the topic and outlines the importance of configuration technologies. It provides a short overview of historical developments (Chapter 2), explains related topics such as recommender systems, software configuration, and product data management (Chapter 3), and provides insights into commercial benefits for organizations that integrate configurators in their business processes (Chapter 4). The Basics (Part 2) introduces the concepts needed for understanding how configuration technologies work. This part helps the reader to develop an answer, for example, to the following questions: What is configuration? What is a configuration model? What is a configuration task (problem)? How can a configuration task be represented on a formal level? Which reasoning approaches exist for solving a configuration task? What are key criteria to be taken into account by configurator user interfaces? How can configuration be applied to support mass customization? The following chapters are included in Part 2. In Chapter 6, Lothar Hotz et al. provide an in-depth introduction to the topic of configuration knowledge representations and related reasoning approaches. This chapter includes a presentation of a UML (Unified Modeling Language) based configuration model, which is used as a working example throughout the book. Consistency management for configuration knowledge is an important issue in industrial environments. Configuration knowledge bases have to determine correct solutions that take into account technical restrictions and constraints related to marketing and sales. In Chapter 7, Alexander Felfernig et al. introduce different consistency management techniques and explain these in the context of an example configuration knowledge base. In Chapter 8, Gerhard Leitner et al. discuss major issues related to the design of configurator user interfaces. Furthermore, Paul Blazek and Frank T. Piller shed light on relationships between the mass customization paradigm and underlying technologies (Chapter 9). Finally, Lothar Hotz and Katharina Wolter introduce a configuration model from the domain of smarthomes (Chapter 10). Advanced Topics (Part 3) provides an overview of ongoing research dedicated to advancing the state of the art in configuration systems. This part of the book helps to answer, for example, the following questions: How can configurator user interfaces be personalized? How can configurations be Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00005-0 © 2014 Elsevier Inc. All rights reserved.

35

36

CHAPTER 5 Overview of the Book

personalized? Answering both of these questions is very relevant in order to tackle the problem of mass confusion that occurs when too many options are presented to the user. How can we automatically test and debug configuration knowledge bases? How can we improve the quality of configuration knowledge bases, for example, by detecting redundant (and therefore often not necessarily needed) constraints? What are major issues related to different psychological theories of human decision-making? How do these theories have an impact on the way users are interacting with a configurator? This part concludes with a discussion of important issues for future research. The following chapters are included in Part 3. Gerhard Friedrich et al. (Chapter 11) build upon the concepts in Chapter 7 and introduce an approach to the automated testing and debugging of configuration knowledge bases. Alexander Felfernig et al. extend the idea of testing and debugging knowledge bases with approaches to automatically identify redundancies in knowledge bases (Chapter 12). Redundant constraints are constraints that can be deleted from the knowledge base without changing the semantics of the knowledge base. In Chapter 13, Juha Tiihonen et al. introduce concepts related to the idea of personalizing configuration processes—in this context different algorithmic approaches are sketched with the goal to proactively support the user within the scope of a configuration process. Decision psychological aspects of consumer decision-making in the context of configuration systems are discussed by Monika Mandl et al. in Chapter 14. The authors focus on different decision-psychological phenomena and their potential impact on the decision making of a user when interacting with a configurator. The Applications of Configuration Technologies (Part 4) entails six business cases that show the application of configuration technologies in different product domains. Four contributions report experiences of deploying configuration technologies in industrial environments, and the remaining two contributions introduce future application domains and related business benefits. The following chapters are included in Part 4. Four chapters report experiences with configuration technologies in real-world scenarios. In Chapter 16, Andreas Falkner and Herwig Schreiner introduce the SIEMENS configuration environment on the basis of a configurator application deployed in the domain of railway interlocking systems. Klas Orsvarn and Morten Bennick report experiences with the Tacton configuration environment in the domain of cement plant equipment (see Chapter 17). Thereafter in Chapter 18, Björn Höfling presents a deployed configurator application in the domain of compressed air systems. Finally, Rick Rabiser et al. motivate the relevance of configuration technologies in the context of configuring documents—feature model technologies are applied in this context (see Chapter 20). The remaining two chapters discuss application areas with related potential impacts—no deployment in an industrial environment took place in these two cases. First, Iulia Nica et al. motivate the application of (re)configuration technologies in the domain of mobile phone network infrastructures (see Chapter 19). Second, Juha Tiihonen et al. discuss the peculiarities of configuration technologies in the context of service and process configuration (see Chapter 21). Configuration Environments (Part 5) entails a discussion of configuration environments on a more technical level. This part includes four commercial and two academic configuration environments. The chapters of this part provide an impression of how the PC configuration model introduced in Chapter 6 can be implemented in the form of a configuration knowledge base when using the corresponding configuration environment. First, Alois Haselböck and Gottfried Schenner introduce the S’UPREME configuration environment from SIEMENS (Chapter 22). Thereafter, Thorsten Krebs provides an overview of the encoway configuration environment (Chapter 23). Lothar Hotz introduces the KONWERK open source configuration environment (Chapter 24). Felfernig et al. introduce the

CHAPTER 5 Overview of the Book

37

Table 5.1 Recommendation of book parts for different reader segments. Reader Segment

Recommended Parts

Industry with no configuration-related knowledge Industry with configuration-related knowledge Industry and researchers interested in learning material Researchers interested in configuration systems

2, 4, 5 2, 3 2, 3, 4, 5 2, 3

(Wikipedia-based) W eeV is environment, which is useful as a simple learning environment for configuration model development (Chapter 25). Furthermore, Juha Tiihonen and Andreas Anderson introduce the VariSales environment (Chapter 26). Finally, in Chapter 27 Albert Haag presents a retrospective of the developments related to the SAP configuration environment. An Appendix (Part 6) concludes this book. It includes an overview of existing commercial configuration environments, an overview of open-source constraint solvers that are especially useful when dealing with less complex configuration scenarios, an overview of configuration-related lexicons and databases (summarizing existing applications of configuration technologies), an overview of existing benchmarks that can be used to compare new (algorithmic) developments with the existing state of the art, and an overview of existing journal special issues and events (conferences and workshops) related to the field of configuration. In order to support the reader in the selection of specific chapters, we provide the following recommendations (see Table 5.1). (1) People from industry with no configuration-related knowledge should take a look at the chapters in Part 2 to gain a basic understanding of the concepts behind configuration systems and then switch to Part 4, which includes a discussion of related business cases. Part 5 is a good complement in terms of a visualization of functionalities of existing configuration environments. (2) People from industry with a configuration-related background are encouraged to take a look at Part 2 and then to move on to Part 3, which includes a discussion of new and future technological developments. (3) Readers interested in the establishment of learning units related to the topic of configuration are referred to Parts 2 through 5 as well as the slides provided with the contents of this book. (4) Researchers new in the field of configuration are referred to the Parts 2 and especially Part 3, which provides an overview of issues for future research that may be of interest for PhD students in the early phase of their work.

This page is intentionally left blank

PART

Basics

2

This page is intentionally left blank

CHAPTER

Configuration Knowledge Representation and Reasoning

6

Lothar Hotz* , Alexander Felfernig† , Markus Stumptner‡ , Anna Ryabokon§ , Claire Bagley¶ and Katharina Wolter* * HITeC

e.V., University of Hamburg, Hamburg, Germany † Graz University of Technology, Graz, Austria ‡ University of South Australia, Adelaide, SA, Australia § Alpen-Adria Universitat ¨ Klagenfurt, Klagenfurt, Austria ¶ Oracle Corporation, Burlington, MA, USA

Abstract: Configuration models specify the set of possible configurations (solutions). A configuration model together with a defined set of (customer) requirements are the major elements of a configuration task (problem). In this chapter, we discuss different knowledge representations that can be used for the definition of a configuration model. We provide examples that help to further develop the understanding of the underlying concepts and include a UML-based personal computer (PC) configuration model that is used as a reference example throughout this book.

6.1 Introduction There is quite a long history of research dedicated to the development of configuration knowledge representation languages (Felfernig et al., 2003; Günter and Kühn, 1999; Jüngst and Heinrich, 1998; Junker, 2006; Mailharro, 1998; McDermott, 1982; McGuinness and Wright, 1998; Mittal and Falkenhainer, 1990; Mittal and Frayman, 1989; Soininen et al., 1998). One of the first configuration systems was R1/XCON, which was built upon a rule-based representation language (McDermott, 1982; Soloway et al., 1987). Rule-based systems operate on a working memory that stores assertions made by rules. Rules are represented in an if-then style. If a rule is activated (given that the if condition is fulfilled) it can modify the contents of the working memory. Experiences showed that a major problem with rule-based systems is the intermingling of (product) domain knowledge and problem solving knowledge (see also Friedrich et al., 20141 ). A consequence is that if product knowledge is changed, rules related to the sequence in which components are integrated in a configuration have to be adapted as well, which triggers enormous maintenance overheads.2 The shortcomings of rule-based approaches were the motivation for the development of model-based knowledge representations that support a clear separation of domain and problem solving knowledge. Mittal and Frayman (1989) introduced a model-based definition of a 1 Chapter

11. are not recommended for larger industrial settings (Faltings and Weigel, 1994) and will not be discussed in detail within the scope of this book. 2 Rules

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00006-2 © 2014 Elsevier Inc. All rights reserved.

41

42

CHAPTER 6 Configuration Knowledge Representation and Reasoning

configuration task that is characterized by: (1) a description of generic components in terms of their properties and relationships and (2) user requirements and preferences regarding functional properties of the solution (configuration). This characterization is a major foundation for configuration research and industry (Junker, 2006). It also includes the idea of separating functional requirements (customer requirements) from the technical properties of a configurable product. A major representative of model-based approaches are constraint-based systems (see, e.g., Freuder, 1997; Tsang, 1993). Related knowledge representations range from static constraint satisfaction (variables and constraints are predefined and are part of the search process from the very beginning (see, for example, Tsang, 1993), dynamic constraint satisfaction (variables are not necessarily active from the very beginning but can be activated within the scope of the search process; Mittal and Falkenhainer, 1990), to generative constraint satisfaction where components and related constraints are generated on-demand within the scope of the search process (see Stumptner et al., 1998). Generative approaches can also be denoted as component-oriented since component types (instead of variables) and meta (generic) constraints (instead of constraints) are taken into account as first-class entities. Examples of configuration knowledge representation in terms of a constraint satisfaction problem (CSP) will be provided in Section 6.2. In the following, graphical representations have been developed with the goal of improving the accessibility (in terms of, e.g., understandability and maintainability) of configuration knowledge, which is crucial especially in commercial settings. One approach to the graphical representation of configuration models are feature models (see, e.g., Kang et al., 1990). Feature models can be represented in the form of a static constraint satisfaction problem (CSP; Tsang, 1993) or in the form of a SAT problem (Gomes et al., 2008). Neumann (1988) and Soininen et al. (1998) introduced configuration ontologies, which define relevant modeling concepts for configuration knowledge representation. These ontologies include modeling concepts that are typically provided in today’s commercial configuration environments; for example, component types, ports, and constraints. Similar ontological concepts as introduced, for example, by Neumann (1988) and Soininen et al. (1998) in terms of a UML profile for configuration knowledge representation, and a formalization of these concepts in first-order logic as well as in description logic has been proposed by Felfernig (2007), and Felfernig et al. (2000a, 2003). Note that in this chapter we focus on the representation of product-related configuration knowledge; knowledge representations related to incremental configuration processes (Sabin and Weigel, 1998) are discussed in detail in Leitner et al. (2014),3 Hotz and Wolter (2014),4 and Hotz and Günter (2014).5 With this chapter, we provide an overview of modeling concepts that are relevant for configuration knowledge representation. In Subsection 6.2.1, we introduce static constraint satisfaction problems as a basic representation mechanism for configuration knowledge. In Subsection 6.2.2, we introduce two types of advanced CSP representations that are dynamic and generative constraint satisfaction problems. Thereafter, in Section 6.3, we discuss graphical configuration knowledge representations (feature models and UML models). On the basis of the latter we introduce a personal computer configuration model. In the other chapters of this book, this UML model is adapted and extended where needed. In Section 6.4, 3 Chapter

8. 10. 5 Chapter 24.

4 Chapter

6.2 Constraint-Based Knowledge Representation

43

we give an overview of different logic-based approaches to configuration knowledge representation. This chapter concludes with a discussion of major advantages and disadvantages of different types of configuration knowledge representations.

6.2 Constraint-Based Knowledge Representation 6.2.1 Static Constraint Satisfaction “Constraint technologies are one of the closest approaches computer science has yet made to the Holy Grail of programming: a user states the problem, the computer solves it.” (Freuder, 1997). Constraint technologies are one of the most successfully applied technologies of Artificial Intelligence (AI) in commercial settings (Brailsford et al., 1999). With these technologies, the knowledge acquisition bottleneck6 is tackled by the means of an easy to understand and easy to use technology. Application examples are configuration (Fleischanderl et al., 1998; Mittal and Frayman, 1989), scheduling (Pinedo, 2012), and recommender systems (Felfernig and Burke, 2008; Jannach et al., 2010). Constraint-based representations are widely used for the definition of configuration models (see, Junker and Mailharro, 2003; Mailharro, 1998). We first focus on static constraint satisfaction problems (SCSPs).

Constraint Satisfaction Problem and Solution We will now introduce a definition of a constraint satisfaction problem (CSP) and its solution. This definition will then be used as a basis for defining a configuration task (problem) and a corresponding configuration (solution). Definition (Constraint Satisfaction Problem – CSP). A constraint satisfaction problem (CSP) can be defined by a triple (V, D, C) where V is a set of finite domain variables {v1 , v2 , . . . , vn }, D represents variable domains {dom(v1 ), dom(v2 ), . . . , dom(vn )}, and C represents a set of constraints defining restrictions on the possible combinations of variable values ({c1 , c2 , . . . , cm }). A solution for a given CSP = (V, D, C) can be defined as follows.

Definition (CSP Solution). A solution for a given CSP = (V, D, C) is represented by an assignment S = {ins(v1 ), ins(v2 ), . . . , ins(vk )} where ins(vi ) ∈ dom(vi ). S is required to be complete; that is each variable of the CSP definition has a value in S and is consistent (i.e., S fulfills the constraints in C).

Configuration Task and Solution Based on this definition of a CSP, we can now introduce the definition of a configuration task (problem) and a corresponding configuration (solution). We introduce two sets of constraints that describe (1) the configuration knowledge base (CKB ) and (2) the user requirements (REQ). Definition (Configuration Task). A configuration task can be defined as a CSP (V, D, C) where V = {v1 , v2 , . . . , vn }, D = {dom(v1 ), dom(v2 ), . . . , dom(vn )}, and C = CKB ∪ REQ. CKB represents the configuration knowledge base (the configuration model) and REQ represents a set of user (customer) requirements. 6 Efforts

triggered by the communication between domain experts and engineers.

44

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Definition (Configuration). A configuration (solution) S for a given configuration task (V, D, CKB ∪ REQ) is represented by an assignment S = {ins(v1 ), ins(v2 ), . . . , ins(vk )} where ins(vi ) ∈ dom(vi ) and S is complete and consistent with the constraints in CKB ∪ REQ.

This definition of a configuration task and its solution is exploited by some of the chapters in this book. This approach to represent a configuration task is primarily used in situations where all variables of the problem definition are relevant for the solution. To better understand the pragmatics of these definitions, we will now present two example configuration models: a configuration model for map coloring and a mobile phone configuration model.

Example: Map Configuration (Map Coloring) Map-coloring can be interpreted as a simple configuration task (problem). The goal of this configuration task is to assign a color to each of the regions of a map in such a way that for each region x on the map the following property holds: all regions y = x that are direct neighbors of x must have a different color (different from the color of x). As an example, we take the map of Australia (see also Russel and Norvig, 2003), which includes the regions of Western Australia (WA), Northern Territory (NT), South Australia (SA), Queensland (Q), New South Wales (NSW), Victoria (V), and Tasmania (T) (see Figure 6.1). These regions must be colored with the colors red, green, and black. Based on this characterization of a map coloring configuration problem, we can define the corresponding configuration task (V , D, C). V = {WA, NT, SA, Q, NSW, V, T} D = {dom(WA)={r,g,b}, dom(NT)={r,g,b}, dom(SA)={r,g,b}, dom(Q)= {r,g,b}, dom(NSW)={r,g,b}, dom(V)={r,g,b}, dom(T)={r,g,b}}

FIGURE 6.1 Territory map of Australia.

6.2 Constraint-Based Knowledge Representation

45

FIGURE 6.2 Map coloring configuration model: graphical representation of a CSP where the nodes represent the variables and the arcs represent constraints.

Finally, we introduce the set of constraints C = CKB ∪ REQ to be taken into account when configuring (coloring) a map. The elements of CKB are those constraints that are defining the restrictions regarding the color combinations of neighborhood territories. CKB = {WA = NT, WA = SA, NT = SA, NT = Q, SA = Q, SA = NSW, SA = V, Q = NSW, NSW = V} A CSP can also be represented graphically in terms of nodes (the variables) and the corresponding constraints (arcs between the variables); Figure 6.2 shows a graphical depiction of the map coloring configuration model. Customer requirements in this context can be preferences (in terms of initial settings) regarding the coloring of the map. For example, we could introduce the singleton requirement REQ = {W A = r }; that is, the color of Western Australia (WA) should be red (r ). Then REQ ∪ CKB is consistent; that is, we are able to determine a solution for the map coloring (configuration) problem. S = {WA = r , NT = g, SA = b, Q = r , NSW = g, V = r , T = r }

Example: Mobile Phone Configuration The following configuration model of a mobile phone is based on the model of a mobile phone software product lines (adapted from Benavides et al., 2010). We will provide a formalization of this model on the basis of the definition of a configuration task given in Subsection 6.2.1.7 See Figure 6.3 for a graphical depiction of the mobile phone configuration model. Our Mobile Phone (MP) model consists of the following elements: each mobile phone has two mandatory elements that are the support of Calls (CA) and the availability of a Screen (SC). A Screen can either be of type Basic (BA), Color (CO), or HighResolution (HR). A mobile phone can (but does not have to) be equipped with a GPS (GPS) feature. Furthermore, a mobile phone can include additional media equipment (Camera (CM) and MPX Player (MPX)). When equipped with a 7 In

Subsection 6.3.1 we will show how to represent similar settings with the notation of feature models (Kang et al., 1990).

46

CHAPTER 6 Configuration Knowledge Representation and Reasoning

FIGURE 6.3 Simple Mobile Phone configuration model (represented as CSP). An abbreviation is used for the constraint representation; for example, CA ↔ MP is the short form of CA = 1 ↔ MP = 1. MP = Mobile Phone, CA = Calls, GPS = GPS, SC = Screen, CM = Camera, MPX = MPX Player, BA = Basic, CO = Color, HR = High Resolution.

GPS, then the phone’s Screen can’t HighResolution Screen.

be of type Basic. A phone with a Camera must be equipped with a

Based on this characterization of the basic properties of our example mobile phone, we can introduce the following configuration task (V , D, C). V = {MP, CA, GPS, BA, CO, HR, SC, CM, MPX} Since we are interested in defining the possible combinations of mobile phone features, we assign to each of the feature variables in V the domain {1,0} ({true, false} is possible as well). The semantics of 1 (resp. 0) is that a feature is active (resp. inactive); that is, included or not included in a configuration. D = {dom(MP) = {1, 0}, dom(CA) = {1, 0}, dom(GPS) = {1, 0}, dom(BA) = {1, 0}, dom(CO) = {1, 0}, dom(HR) = {1, 0}, dom(SC) = {1, 0}, dom(CM) = {1, 0}, dom(MPX) = {1, 0}} Finally, we specify the constraints C = CKB ∪ REQ.8 Since we are not interested in empty configurations, we introduce the constraint MP = 1. CKB = {MP = 1, CA ↔ MP, GPS → MP, SC ↔ MP, CM → MP, MPX → MP, (BA ↔ (¬ CO ∧ ¬ HR ∧ SC)) ∧ (CO ↔ (¬ BA ∧ ¬ HR ∧ SC)) ∧ (HR ↔ (¬ CO ∧ ¬ BA ∧ SC)), ¬ BA ∨ ¬ GPS, CM→ HR} Customer requirements regarding a concrete mobile phone configuration could be the following: REQ = {GPS = 1}; that is, GPS should be included. In our example, REQ ∪ CKB is consistent and a possible configuration (solution) S is: S = {MP = 1, CA = 1, GPS = 1, BA = 0, CO = 1, HR = 0, SC = 1, CM = 0, MPX = 0} 8 CSP solvers usually support the integration of additional constraint types such as arithmetic constraints (e.g., x = y + z), meta-constraints (e.g., all different (x1 , . . . , xk )), and relational constraints (e.g., x ≤ y).

6.2 Constraint-Based Knowledge Representation

47

Solution Search in Static CSPs There is plenty of literature on algorithms that can be used for solving static constraint satisfaction problems (e.g., Mackworth, 1977; Rossi et al., 2006; Russel and Norvig, 2003; Tsang, 1993). The basic approach of CSP algorithms is to apply backtracking in combination with a couple of additional mechanisms that altogether focus on variable domain size reduction during search (Russel and Norvig, 2003). One basic principle for reducing the domain size of variables is node-consistency, which requires that those values of a variable domain that are inconsistent with an unary constraint are eliminated as options (for these options there does not exist a solution). Arc-consistency (AC) is a property that must be fulfilled by combinations of variables v1 and v2 that are connected via a binary constraint cb 9 : each value in the domain of v1 must have at least one corresponding value in the domain of v2 such that cb is fulfilled. Note that arc-consistency is directed; if variable v1 is arc-consistent with variable v2 this does not necessarily mean that v2 is arc-consistent with v1 . In the following example we take a look at the variables WA and NT of our map configuration (coloring) example (see Figure 6.2). Although AC is restricted to binary constraints, this does not restrict its applicability since every n-ary constraint can be transformed into a corresponding set of binary constraints (e.g., Bacchus and vanBeek, 1998). Example of node-consistency and arc-consistency. The original domain of WA = {r,g,b}. Since we defined {WA = r} as a requirement, WA is node-consistent and the values {g,b} get removed from its domain. In order to ensure arc-consistency between WA and NT, the value {r} needs to be removed from NT’s domain definition. Now, each value in the new domain of WA has a consistent corresponding value in the domain of NT and vice versa. Another important principle in variable domain size reduction is forward checking: Depending on the value selected for the current variable, the values of the instantiated variables that can’t be a support for the selected value are eliminated from their corresponding domains. An example is depicted in Figure 6.4. Search algorithms for CSPs are able to support optimization, which helps to minimize (e.g., the overall price of a configuration) or maximize (e.g., the failure safety of an equipment) solution parameters (Pitiot et al., 2013).

FIGURE 6.4 A simple example of forward checking. The variables WA and NT already have assigned values (r and g ). The only possible remaining value for SA is b; r and g do not have to be checked for consistency with the settings of WA and NT. 9A

constraint that refers to exactly two variables.

48

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Finally, tuning the performance of solution search is typically done with basic strategies of variable and value orderings (Russel and Norvig, 2003), with advanced approaches such as symmetry breaking (Kiziltan and Hnich, 2001) and machine learning based acquisition of search strategies (Terashima– Marin et al., 2008), with local search algorithms (Li et al., 2006), and different techniques of knowledge compilation such as binary decision diagrams (BDDs; Andersen et al., 2010) and solution automata (Amilhastre et al., 2002). For further literature on related algorithms and optimization approaches we refer to Brailsford et al. (1999); Rossi et al. (2006); Russel and Norvig (2003), and Tsang (1993).

Excursus: SAT Problems For a given propositional formula, the goal of SAT solving (see, e.g., Claessen et al., 2008) is the determination of a variable assignment such that the formula evaluates to true. A propositional logic formula is in a conjunctive normal form (CNF) when it is represented in the form of conjunctions of disjunctions of literals. For a Boolean variable X , a literal is defined as X or its negation ¬X . Each of the disjunctions is denoted as a clause. A SAT problem (satisfiability problem) is to identify an assignment to the given Boolean variables in such a way that the mentioned formula in CNF evaluates to true. This is the case if each clause has at least one literal that evaluates to true. For a more detailed discussion of SAT solving and related algorithms, refer to Claessen et al. (2008). An example of the translation of a given static CSP into a corresponding SAT representation follows. Example: SAT encoding of a static CSP. In order to show the basic principle of how to translate a static CSP into a corresponding SAT representation, we take the variables WA and NT from our working example (map coloring). In a static CSP representation the variable domains can be specified as dom(WA)= {r,g,b} and dom(NT)= {r,g,b}. In the corresponding SAT representation we have to introduce Boolean variables where each domain value of the original variables is represented by its own (Boolean) variable. In our example this translation results in the variables WAr , WAg , WAb , NTr , NTg , NTb . Each of these variables has the domain {true, false} ({1,0}). The translation of the constraint WA = NT into a clausal form could look like: (¬WAr = 1∨¬NTr = 1)∧(¬WAg = 1∨¬NTg = 1)∧(¬WAb = 1∨¬NTb = 1) ∧ (¬WAr = 0 ∨ ¬WAg = 0 ∨ ¬WAb = 0) ∧ (¬NTr = 0 ∨ ¬NTg = 0 ∨ ¬NTb = 0). With this, we assure that (1) the two territories do not have the same color and (2) both territories have a color assigned. As can easily be seen, our Mobile Phone configuration model can directly be translated into a corresponding SAT representation, since the variable domains in the CSP are already of type Boolean. For further related work refer to Janota (2008) and Janota et al. (2010).

6.2.2 Advanced CSP Approaches On the basis of the static CSP approach, numerous extensions have been implemented in order to improve expressiveness and the efficiency of the underlying reasoning algorithms. An in-depth analysis of existing CSP variants is beyond the scope of this book; however, we will now discuss some representative ones that have found their way into commercial configuration environments.

Dynamic Constraint Satisfaction Configuration tasks very often include variables that do not have to be taken into account in specific configuration contexts. For instance, in our mobile phone configuration example, the variable Camera is not relevant if the user is interested only in monochrome (basic) displays. In the mobile phone

6.2 Constraint-Based Knowledge Representation

49

configuration example in Subsection 6.2.1, the property of variable irrelevance is implemented in terms of feature deactivation; that is, if no Camera is part of the configuration, the value of this variable is set to 0 (false). However, if we want to introduce a variable Camera with the domain {TypeA, TypeB, TypeC} representing three different camera types, we would have to introduce an additional domain value noval that expresses the fact that the camera is not part of the configuration. As can be seen from this simple example, there is a need to include concepts that support reasoning over variable states (active, inactive). In order to take into account the requirement of leaving out irrelevant variables during the search process, Mittal and Falkenhainer (1990) introduced the concept of dynamic constraint satisfaction (DCSP), where a constraint solver is also able to reason about the activity states of variables. The following example shows such an activation constraint. Example of an activation constraint. For a variable CM (the camera) with the domain {TypeA, TypeB, TypeC} we could define the following activation constraint: HighResolution (HR) = yes → active(CM). If the precondition is not fulfilled, there is no need for CM to get assigned a value (i.e., be activated). Such a reasoning about activity states in DCSPs is based on predefined activity constraints. A formal discussion of the properties of DCSPs can be found in Bowen and Bahler (1991). The concept of variable activation has also been applied in other approaches. For example, generative constraint satisfaction (GCSP) based systems (Stumptner et al., 1998) generalize the concept of variable activation to the concept of component and constraint activation. The configuration environment of SIEMENS is based on such a generative approach (see also Falkner and Schreiner, 2014).10

Generative Constraint Satisfaction Major drawbacks of static (and dynamic) CSPs include representational limits in terms of dealing with variables and variable values instead of component types and corresponding components (instances). Another disadvantage is that static CSPs are limited with regard to the description of configuration problems in which the size and structure of configurations cannot be estimated beforehand. Generative constraint satisfaction (GCSP) helps to overcome these problems by moving variables and corresponding constraints to the level of component types and meta-constraints (generic constraints). Generic constraints (constraint schemata) help to identify and generate relevant additional components and variables that are relevant in the current configuration context. Constraints are referred to as “generic” since they apply individually to all components of the types on which the constraints are defined. For example, a constraint preventing a particular type of CPU from being placed on a particular type of Motherboard applies to all CPUs of that type although it is only defined in the knowledge base once. Components in GCSP settings are represented in terms of a finite domain variable (the domain of the variable corresponds to the different types a component can take). Activation constraints are used, for example, to generate new property variables based on the assignment of a type to a component variable. A Generative Constraint Satisfaction Problem (GCSP) can be defined as follows (Stumptner et al., 1998). Definition (Generative Constraint Satisfaction Problem – GCSP). A generative constraint satisfaction problem can be defined by a triple (CV, P, Ŵ) where C V is a possibly infinite set of component variables. The domain of each variable from CV is a finite set T = {τ1 , τ2 , . . . , τn } of component types. P = { p1 , p2 , . . . , pn } is a set of property (attribute) names. Furthermore, there exists a set 10 Chapter

16.

50

CHAPTER 6 Configuration Knowledge Representation and Reasoning

D = {C V , D1 , D2 , . . . , Dn } of domains and a function Dom that maps pairs of the form (property name, type) to elements of D. The sets D1 , D2 , . . . , Dn are called atomic domains (i.e., they contain numeric or symbolic values, but are distinct from C V ). The name of a property variable is composed from the name of the originating component and the property name; for example, if property p ∈ P is defined for component c ∈ C V , then the property variable is named c. p. Finally, Ŵ is a finite set of generic constraints including activation and resource constraints. GCSP representations allow the definition of ports that represent connection points between different components. In GCSPs (Stumptner et al., 1998), ports are represented by properties (attributes) that permit other components as values. Partonomies (part-of structures; see Subsection 6.3.2) can be represented on the basis of such port definitions. Inheritance relationships (related to a generation hierarchy) are represented on the basis of (generic) constraints that refer to component type domains. Example GCSP component type. A component type PC (P) can be represented as follows using a GCSP-style notation (see, e.g. Stumptner et al., 1998). This definition of the basic properties of a PC is related to the graphical configuration model depicted in Figure 6.7. As can easily be seen, GCSP approaches have a more intuitive knowledge representation, which is inspired by object-oriented data models combined with constraints (see, e.g., Bowen and Bahler, 1991; Neumann 1988; Puget and Albert, 1991). PC P DESCRIPTION: P.name := [String]; P.price := [Integer]; P.usage := {’internet’,’scientific’,’multimedia’}; P.efficiency := {’A’,’B’,’C’}; P.PORTS := {screen-of-pc-1[Screen], screen-of-pc-2[Screen], hdunit-of-pc-1[HDUnit], ...}; P.screens := ; P.mb := ; P.hdunits := ; GCSP constraints are represented in the context of a specific component type. As such this approach is very similar to constraint-including object-oriented languages such as the Unified Modeling Language (Booch et al., 2005) that includes the Object Constraint Language (OCL; Warmer and Kleppe, 2003). For an overview of the application of UML and OCL for configuration knowledge representation refer to Felfernig (2007) and Felfernig et al. (2000a). An example of a UML-based configuration model is introduced in Subsection 6.3.2. Example GCSP constraint. A GCSP constraint that describes the fact that the energy efficiency required by the user must be supported by the motherboard mb, can be represented as follows. This example shows how constraints can “navigate” through the component partonomy defined for the GCSP. PC P DESCRIPTION: P.efficiency = P.mb.efficiency; Usually, GCSP environments include a graphical front end that helps to define the configuration model more easily in an object-oriented fashion. Such an abstraction level improves the quality of

6.2 Constraint-Based Knowledge Representation

51

knowledge acquisition support. For further information regarding GCSP-based configuration knowledge representations refer to Stumptner et al. (1998). Note that we do not need to introduce a specific definition of a configuration problem for GCSPs since we can reuse the definition given in Subsection 6.2.1.

Solution Search in Advanced CSPs Constraint solving in other domains is often not confronted with configuration-specific requirements. For example, a user interacting with a configurator is in the need of explanations (Junker, 2004; Sinz et al., 2007) in terms of why a solution has been identified or why no solution could be found (Falkner et al., 2011; Junker, 2004). In situations where no solution can be found for a given set of requirements, explanations represent minimal sets of requirements that have to be adapted such that a solution can be identified (Felfernig et al., 2004, 2012; Reiter, 1987). In contrast to static CSPs, generative CSPs not only need to choose values for individual variables but also need to manage the generation of variables (components) and constraints within the scope of a search process. Decisions regarding the generation of variables are quite important since they directly influence solution quality. For example, if three hard disk drives are generated, although two is more than enough for the given set of requirements, the resulting configuration is clearly suboptimal. This is also referred to as over-fulfilled function (see, e.g., Junker, 2006). In order to avoid such problems, decisions regarding variable (component) instantiation have to follow a set of properties (heuristics). For example, it often makes sense to configure a product top down; that is, to add new components (variables) for a lower level of the partonomy, if components on a higher level have already been instantiated. For a detailed discussion of instantiation strategies refer to Junker (2006). Example of Dynamic Component Creation. Assume a PC configuration situation where pc-1 (a PC instance) has (e.g., by explicit user interaction) a HDUnit (hdunit-1) and two HDisks (harddisks: hdisk-1 and hdisk-2) built in, giving a total capacity of 2 TB (left-hand side of Figure 6.5). However, a resource constraint (the one in Figure 6.5) requires a total capacity of at least 4 TB for each PC. Since no HDUnit with a free disk port is available, a new one must be created. The system can then create new HDisks (hdisk-3 and hdisk-4) with a corresponding HDUnit (hdunit-2) such that the capacity is satisfied (let us assume for simplicity that two HDisks with capacity 1 TB are chosen). Because they are of that type, the port and attribute variables defined for that type are created. This includes capacity (assigned 1 TB) and a port called hdunit-of-hdisk that is used to express the part hierarchy. The definition of HDisk would specify that the hdunit-of-hdisk port needs to be connected to a HDUnit component. The port in a HDUnit that could take the other end of the connection would be the hdisk-of-hdunit port. For a more detailed discussion of related reasoning approaches refer to Junker (2006), Mailharro (1998), and Stumptner et al. (1998). One of the major ideas of generative constraint satisfaction (see Stumptner et al., 1998) is to generalize the configuration problem representation from individual variables and constraints toward problem definitions with component types and generic constraints. Such an approach is also known as componentbased or component-oriented configuration where configuration domain-specific concepts (e.g., components, attributes, and part-of hierarchies) can directly be used when designing a configuration model. Approaches supporting component-oriented configuration can be seen as an important step toward the development of configuration knowledge representations that help to improve the efficiency of model development as well as to increase the accessibility of configuration knowledge for product experts (with no configuration-related technical background). As already mentioned, graphical knowledge

52

CHAPTER 6 Configuration Knowledge Representation and Reasoning

FIGURE 6.5 Simple GCSP dynamic component creation example. The constraint representation is simplified (i.e., it does not directly correspond to the GCSP constraint representation used in Stumptner et al., 1998).

representations have been developed to more easily represent and manage configuration knowledge and increase its accessibility, which is crucial for commercial configurator projects. In the following Subsections (6.3.1–6.3.2) we introduce two basic approaches to a graphical configuration knowledge representation.

6.3 Graphical Knowledge Representation 6.3.1 Feature Models Feature models have been developed in the Software Engineering community with the goal of representing variability properties in software product lines (see, e.g., Batory, 2005; Czarnecki et al., 2005; Felfernig et al., 2013a; Kang et al., 1990). We show how feature models can be used to represent static CSP-based configuration models. Note that each static CSP can be easily transformed into a corresponding Boolean CSP (Gomes et al., 2008) by translating individual variable domain values into corresponding Boolean variables; the constraints have to be adapted correspondingly (for an example see Subsection 6.2.1). In this section we show how to represent the mobile phone configuration model (Subsection 6.2.1) as a feature model (see Figure 6.6). Feature models are based on a knowledge representation that

6.3 Graphical Knowledge Representation

53

FIGURE 6.6 Feature model of a mobile phone (adapted version of Benavides et al., 2010). This feature model is equivalent to the constraint-based representation of Figure 6.3.

can be used to model the variability of software product lines. The idea is to represent all allowed variants of a configurable product in one integrated graphical model. If we compare the constraintbased representation of Figure 6.3 with the feature model representation of Figure 6.6 it becomes clear that the latter has a more compact and understandable representation.11 The feature model (configuration model) of a mobile phone (see also Subsection 6.2.1) consists of two parts. The structural part defines a hierarchical relationship between the features of the feature model. The constraint part integrates additional constraints that define so-called cross-hierarchy restrictions. In feature models, all these additional constraints are defined on a graphical level and, typically, no additional constraints are needed to specify variability properties. Structural properties in a feature model are defined in terms of features and their relationships (mandatory, optional, alternative, and or). Requires and excludes are the two constraint types that are used for the specification of feature models. We will now discuss in an informal fashion the semantics of the modeling concepts offered by feature models. We will do this on the basis of our working example of mobile phone configuration (the corresponding Mobile Phone feature model is depicted in Figure 6.6).

Mobile Phone Feature Model: Structure The structure of a feature model is defined on the basis of features, relationships, and constraints. The following modeling concepts (modeling facilities) can be used to develop a feature model (Kang et al., 1990).12 Compared to static CSP representations, feature models are less expressive. For example, basic arithmetic expressions, meta constraints, and relational expressions cannot be directly included in feature models. 11 For

large and complex graphical models, additional structuring mechanisms are needed. For a detailed discussion of structuring mechanisms for configuration knowledge, refer to Felfernig et al. (2000b) and Felfernig and Zanker (2000). 12 For further feature model notations refer to Batory (2005) and Czarnecki et al. (2005).

54

• •

•

•

•

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Feature: A feature has a unique name and is used to describe the possible states of a feature (included in or excluded from a certain configuration). The root feature (i.e., the feature Mobile Phone in our working example) is contained in every configuration. Mandatory Relationship: A mandatory relationship between two features describes the fact that if the higher-level feature is part of a configuration, then the lower-level feature (also called subfeature) must be part of the configuration. The lower-level feature can only be part of the configuration, if the higher-level feature is included. For example, if the feature Mobile Phone is part of the configuration, the feature Calls must be part of the configuration as well. Since Mobile Phone is the root feature, Calls and Screens must be part of every configuration. Optional Relationship: An optional relationship between two features describes the fact that if the higher-level feature is part of the configuration, the lower-level feature can be part of the configuration. The lower-level feature can only be part of the configuration if the higher-level feature is part of the configuration. An example of an optional feature is Camera. Alternative Relationship: An alternative relationship between an upper-level feature u and the lowerlevel features l1 , l2 , . . . , ln describes the fact that if u is part of the configuration, then exactly one of the lower-level features must be part of the configuration. The lower-level feature can only be part of the configuration if the higher-level feature is included. In our example, Screen and its subfeatures represent an alternative relationship. Or Relationship: An or relationship between an upper-level feature u and lower-level features l1 , l2 , . . . , ln describes the fact that if u is in a configuration, at least one of the lower-level features must be part of the configuration. Such a setting can easily be included in our feature model by the addition of a subfeature Media to Mobile Phone with the optional Media subfeatures Camera and MPX (see Benavides et al., 2010).

Mobile Phone Feature Model: Constraints Constraints of a feature model represent restrictions that have to hold between the features. Constraint types that are typically supported by feature model languages are the following (Kang et al., 1990): • •

Requires: A requires constraint between two features ( f 1 requires f 2 ) denotes the fact that if feature f 1 is included in the configuration, feature f 2 must be included as well. For example, if a Camera is included in a configuration, a high-resolution Screen must be included as well. Excludes: An excludes constraint between two features ( f 1 excludes f 2 ) denotes the fact that both f 1 and f 2 must not be part of the same configuration. For example, Basic Screen must not be combined with GPS. For further discussions of feature model representations refer to Benavides et al. (2010).

Mobile Phone Configuration (Solution) A configuration (solution) for a configuration task defined by a feature model and a corresponding set of customer requirements is represented by a list of features and an indication for each feature whether it is active or inactive. An example mobile phone configuration was already determined by the static constraint-based approach discussed in Subsection 6.2.1.

6.3 Graphical Knowledge Representation

55

Table 6.1 Semantics of feature models defined in terms of constraints (propositional logic). Features are represented by Boolean variables. Relationship/Constraint

Semantics

mandatory(P,C) optional(P,C) or (P, C1 , C2 , . . . , Cn ) alternative (P, C1 , C2 , . . . , Cn ) requires(P,C) excludes(P,C)

P↔C C→P P ↔ (C1 ∨ C2 ∨ . . . ∨ Cn ) (C1 ↔ (¬C2 ∧ . . . ∧ ¬Cn ∧ P )) ∧ (C2 ↔ (¬C1 ∧ ¬C3 ∧ ... ∧ ¬Cn ∧ P )) ∧ . . . ∧ (Cn ↔ (¬C1 ∧ . . . ∧ ¬Cn−1 ∧ P )) P→C

¬P ∨ ¬C

Semantics of Feature Models The semantics of feature models can be defined using the static constraint representation introduced in Subsection 6.2.1. If we want to express the optional relationship between Mobile Phones and GPS, we can express this relationship in terms of the constraint GPS → Mobile Phones. If our goal is to translate a feature model into a static CSP representation, the rules depicted in Table 6.1 can be applied. In this definition, P represents the higher-level feature and C a lower-level feature that has a relationship to P. Solution search for feature models can be implemented on the basic algorithms that are able to solve static constraint satisfaction problems (SCSPs) or satisfiability (SAT) problems.

6.3.2 UML Configuration Models We now introduce a UML-based configuration knowledge representation13 that can also be used in complex domains where size and structure of configurations are unknown beforehand. In this context, we introduce a configuration model of personal computers (PCs), which is used as a working example in this book. It consists of two major parts: (1) The basic structure of a PC is represented in terms of a partonomy with associated generalization hierarchies (see Figure 6.7) and (2) additional constraints that restrict the combination of individual components. Some basic constraints (gc1, gc2, gc3) are directly integrated in the configuration model of Figure 6.7; the remaining ones ( pr c1, pr c2, r esc1, r esc2, cr c1, cr c2, cr c3, cr c4, compc1, compc2, compc3) are introduced textually in Table 6.2.14 The modeling facilities introduced in the following can be seen as major concepts needed for the design of a configuration model (Falkner and Haselböck, 2013; Felfernig, 2007; Felfernig et al., 2000a, 2001, 2003; Soininen et al., 1998). For the representation of configuration models in UML we rely on the notation of class diagrams; no further notations such as component diagrams or sequence diagrams are needed in this context. 13 Unified

Modeling Language (Booch et al., 2005). a detailed discussion of how to represent these constraints using the UML constraint language OCL (Warmer and Kleppe, 2003) refer to Felfernig (2007).

14 For

56

CHAPTER 6 Configuration Knowledge Representation and Reasoning

1..1 1..1 0..1

PC usage: [internet, scientific, multimedia] efficiency: [A,B,C] maxprice: [0..2500] price: [0..2500]

1..2

MB efficiency: [A,B,C] price: [0..350]

HDUnit price: [0..1000]

InternetConn price: [50]

1..1 1..4 HDisk capacity: [integer] price: [integer]

1..1 1..2

1..1

DiskPort

4..4 0..1 1..1 connected

OS hdcapacity: [0..20] price: [0..500]

Application hdcapacity: [200] price: [50]

1..2 OSBeta hdcapacity: [13] price: [500]

[gc2] MedStoreC price: [500]

MaxStoreDisk capacity: [1000] price: [500]

1..*

1..1

CPU clockrate: [slow, medium,fast] price: [0..150]

MBSilver efficiency: [B] price: [250]

1..1

MedStoreDisk capacity: [200] price: [200]

1..1

1..1

Screen efficiency: [A,B,C] price: [200, 150, 100]

1..1

HDController price: [0..500] 1..1

1..1 1..2

1..1 1..1

MBDiamond efficiency: [A] price: [350]

MaxStoreC price: [500]

CPUD clockrate: [fast] price: [150]

[gc3]

OSAlpha hdcapacity: [6] price: [100]

[gc1]

ControllerPort

component type with attributes

CPUS clockrate: [medium] price: [100]

association-name

partof association (composite) generalization (disjoint&complete)

[constraint-name] [constraint-name]

association requires incompatible

FIGURE 6.7 PC configuration model in UML. In addition to the included constraints {gc1, gc2, gc3}, {prc1, prc2, resc1, resc2, crc1, crc2, crc3, crc4, compc1, compc2, compc3} are introduced in Table 6.2.

The major motivation for applying UML notations for configuration modeling is that the language is a de facto software engineering industry standard and thus more easily accessible for the stakeholders in a development project. Furthermore, it can be directly translated into predicate logic (Falkner and Haselböck, 2013; Felfernig, 2007; Felfernig et al., 2000a, 2003). For a discussion of a UML-based configurator application development process refer to Friedrich et al. (2014)15 .

Computer Configuration Model in UML: Structure In a configuration model (see Figure 6.7), the structure of a configurable product is defined on the basis of the modeling facilities component types (concepts or classes), associations with multiplicities, and generalizations. Note that existing commercial configuration environments do not directly support UML-based representations but typically include similar modeling facilities that allow the representation of partonomies, generalization hierarchies, and constraints. •

Component types: A component type has a unique name and is characterized by a set of attributes. Attributes are defined on the basis of datatypes (the datatype of each attribute is defined in [datatype],

15 Chapter

11.

6.3 Graphical Knowledge Representation

57

Table 6.2 Constraints related to the configuration model shown in Figure 6.7. Name

Description

gc1

CPUs of type CPUS are incompatible with motherboards of type MBDiamond.

gc2

CPUs of type CPUD are incompatible with motherboards of type MBSilver. Each OS of type OSAlpha requires a CPU of type CPUD. The price of one harddisk unit (HDUnit) is determined by the prices of the disks (HDisk) and controllers (HDController) part of the HDUnit. The price of one personal computer (PC) is determined by the prices of the HDUnits, the motherboard (MB), the CPUs, the operating system (OS), the Screens, additional applications (Applications), and the Internet connection (InternetConn). The computer price must be less or equal to the maxprice defined by the customer. The consumed hdcapacity (consumed by instances of component type OS and Applications) must be less or equal to the produced capacity (produced by instances of type HDisk). Intended internet usage or multimedia usage (attribute of PC) requires the existence of an Internet connection (InternetConn). scientific usage requires CPUs of type CPUD. The required energy efficiency (attribute efficiency of PC) must be supported by the MB. The required energy efficiency (attribute efficiency of PC) must be supported by the included Screens. The price of an efficiency A Screen is 200 units. The price of an efficiency B Screen is 150 units. The price of an efficiency C Screen is 100 units.

gc3 prc1 prc2

resc1 resc2

crc1 crc2 crc3 crc4 compc1 compc2 compc3

•

which can denote a constant, an enumeration, or a range). For example, maxprice[0..2500] specifies an integer range attribute of the component type PC. In the examples in this book, attributes are single-valued; that is, no attribute has more than one value. Associations and Multiplicities: The part-of modeling facility is used to describe part-of associations between component types. In its simplest form, these associations are assumed to be of type composite (not shared); this means that no instance (component) of a component type can be part of more than one instance (whole component). For example, each CPU is part of exactly one MB (motherboard) and each MB consists of one or two CPUs. Note that we apply multiplicities to further describe associations between component types. Other examples of multiplicities are the following: each PC (personal computer) consists of one or more Applications (no upper limit defined here) and each Application is part of exactly one PC. Each harddisk (HDisk) has exactly one DiskPort and each DiskPort is associated with one HDisk (within the same HDUnit). Furthermore, each DiskPort

58

•

CHAPTER 6 Configuration Knowledge Representation and Reasoning

is connected with a ControllerPort. Note that additional types of associations are included in the individual book chapters where needed. Generalizations: This modeling facility relates two or more component types through a subset relation. The generalization relationship between subtypes and supertype (or the inverse specialization relationship between supertype and subtypes) can be characterized as disjoint and complete. Disjointness means that each instance of a component type X can be assigned to only one of the subtypes of X. For example, each CPU is either of type CPUS or CPUD but not both. Completeness means that each instance is assigned to one of the leaf nodes of the generalization hierarchy. Furthermore, generalization hierarchies in the configuration context typically do not allow multiple inheritance. Again, further modeling facilities with different semantics are introduced in the other chapters of this book where needed. Note that for reasons of simplicity no definition of specific application types is included in our example; it is assumed that each instance of type Application has the same required hdcapacity (200) and the same price, which is 50. In a complete model of a personal computer additional subtypes would be included or defined as part of a corresponding component catalog.

Computer Configuration Model in UML: Constraints Constraints represent restrictions that have to hold between attributes and/or component types. Constraints frequently used in configuration models are now explained on the basis of our PC configuration model (see Table 6.2).16 We differentiate between the following types of constraints: (1) Constraints that are directly integrated into the configuration model depicted in Figure 6.7 are denoted as graphical constraints (gci ∈ GC). (2) Constraints regarding the pricing of a configurable product can be defined as part of the configuration model. In many real-world scenarios pricing constraints (policies) are not part of the configuration model but rather implemented as a separate pricing component. We denote the set of pricing constraints as P RC = ∪ pr ci . (3) Constraints restricting the production and consumption of resources are denoted as resource constraints (r esci ∈ R E SC). (4) Constraints that define in which context which additional components have to be part of a configuration (solution) are denoted as requires constraints (cr ci ∈ C RC). Requires constraints {cr c1–cr c3} are defined in addition to the ones already contained in GC. (5) Restrictions regarding the way in which different components (instances of component types) can be combined with each other are defined on the basis of compatibility constraints (compci ∈ C O M PC). The compatibility constraints {comp1–comp3} are defined in addition to the ones already contained in GC. The graphical constraint gc1 describes an incompatibility, which is the complement of a compatibility. Compatibilities are used in cases where the number of allowed combinations of components (or attribute values) is low. Alternatively, if the number of incompatibilities is low, incompatibility constraints are used. Quite often, the term compatibility constraint denotes both compatibilities and incompatibilities. All the constraints of the configuration model CKB = GC ∪ P RC ∪ R E SC ∪ C RC ∪ C O M PC 17 together with a set of customer requirements are major elements of a configuration task that can be solved by a configurator (configuration system). 16 Formalizations

of these constraints are introduced in Subsection 6.4.1. that for simplicity we take into account only these specific types of constraints. However, industrial configuration environments typically allow the definition of further constraints that are not restricted to the categorization used here.

17 Note

6.4 Logic-Based Knowledge Representation

59

FIGURE 6.8 Configuration (solution) depicted as a UML instance diagram.

Computer Configuration (Solution) A configuration (solution to a configuration task) can be represented as a UML instance diagram; an example of such a diagram is depicted in Figure 6.8. The diagram depicts concrete components (instances of the classes depicted in the configuration model of Figure 6.7).

6.4 Logic-Based Knowledge Representation 6.4.1 First Order Logic (FOL) The semantics of UML modeling facilities is explained on the basis of the configuration model depicted in Figure 6.9. This is a fragment of our PC configuration model of Figure 6.7, which includes the component types {PC, MB, MBDiamond, MBSilver, CPU, CPUS, CPUD, OS, OSAlpha, OSBeta} and the constraints {gc1, gc2, gc3, prc2’, resc1} (see Table 6.3).18 In order to define the semantics of UML-based configuration models, we will apply a decidable subset of first-order logic (FOL). This is in the line of research dedicated to the formalization of component-oriented representations (see, e.g., Falkner and Haselböck, 2013; Felfernig, 2007; Felfernig et al., 2000a, 2003; Schröder et al., 1996).

Configuration Task and Solution We will now introduce a predicate logic-based definition of a configuration task (problem) and its solution, which is used in the remaining sections of this chapter. This definition is based on Felfernig et al. (2004, 2003). From now on we concentrate on a generalized (component-oriented) knowledge 18 We

reduced the number of model elements for the purpose of understandability.

60

CHAPTER 6 Configuration Knowledge Representation and Reasoning

FIGURE 6.9 Fragment of the PC model (adapted part of Figure 6.7).

Table 6.3 Constraints related to the configuration model in Figure 6.9. Name

Description

gc1

CPUs of type CPUS are incompatible with motherboards of type MBDiamond

gc2

CPUs of type CPUD are incompatible with motherboards of type MBSilver Each OS of type OSAlpha requires a CPU of type CPUD The price of one personal computer (PC) is determined by the prices of the motherboard (MB), the CPUs, and the operating system (OS) The computer price must be less or equal to the maxprice defined by the customer

gc3 prc2’ resc1

representation based on component types and generic constraints (similar to the concepts also provided by generative constraint satisfaction approaches; Mailharro, 1998; Stumptner et al., 1998). Definition (Configuration Task). A configuration task can be defined as a triple (CKB , REQ, CLANG) where CKB and REQ are sets of logical sentences and CLANG is a set of predicate symbols. CKB represents the configuration model and REQ specifies particular system (customer) requirements.

6.4 Logic-Based Knowledge Representation

61

A configuration CONF is described by a set of positive ground literals whose predicate symbols are in CLANG. Definition (Configuration (Solution)). Given a configuration task (CKB , REQ, CLANG), a configuration CONF is consistent if and only if CKB ∪ REQ ∪ CONF is satisfiable. A configuration is valid if it is consistent and a set of completeness axioms related to CONF is fulfilled. CONF together with the  = CONF ∪ AX. corresponding completeness axioms is denoted as CONF

In order to be able to guarantee the completeness property, we have to introduce an additional formula for each of the predicate symbols in CLANG—the so-called completeness axioms (AX; Felfernig et al., 2004). These axioms help to deduce the negation of all possible instances of literals whose predicate symbols are in CLANG with the exception of the positive ground literals contained in CONF; that is, all instances of predicates not explicitly described in CONF are negated (for an example see Table 6.6). This process is also known as Clark Completion (see Russel and Norvig, 2003).

Semantics of UML Configuration Models The first step in formalizing a configuration model is to define the needed component types, attributes, and relationships in terms of FOL unary and binary predicates (see Table 6.4). For each attribute, we have to restrict the allowed attribute values in the context of a certain class. For example, the price of a MB can have a value between 0 and 350 whereas the price of a CPUS is restricted to the value of 100. Thereafter, we define the part-of relationships between component types; in Table 6.4 this is exemplified on the basis of the part-of relationship between MB and CPU. The semantics of generalization (isa) hierarchies is assumed to be disjoint and complete. For example, each MB is either an MBDiamond or an MBSilver. At the same time, a motherboard cannot be both an MBDiamond and an MBSilver. All rules for translating UML configuration models into a corresponding logic-based representation can be found in Felfernig (2007), and Felfernig et al. (2000a, 2003). In order to specify a configuration task we also need to define a set of customer requirements (REQ). These are represented as facts that have to be taken into account by the configurator (see Table 6.5).

Computer Configuration (Solution) in FOL A configuration can be interpreted as an assignment to all the decision points that are specified in the configuration model. Such an assignment is complete if all decision points are instantiated; it is consistent if all the constraints in CKB ∪ REQ are fulfilled. Finally, the assignment is valid if it is consistent and complete. A solution to the configuration task defined by our example is shown in Table 6.6.

6.4.2 Logic-Based Configuration We used FOL to specify the semantics of modeling concepts that can be used for the development of a configuration model. In this section, we introduce logic-based approaches, which can be applied to solve a configuration task to calculate a solution (configuration).

Answer Set Programming Answer Set Programming (ASP) emerged in the late 1990s as an approach to the declarative modeling and solving of computational problems. The paradigm is a result of intensive research in the areas of

62

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Table 6.4 Example formalizations of the model (CKB ) depicted in Figure 6.9. getcpus denotes a collection operator (Felfernig et al., 2000a) that collects all cpus connected with motherboard Y . For reasons of readability we limit the example to attribute range restrictions (e.g., PC(efficiency)). Modeling Facility

Example in FOL

Component types

{PC/1, MB/1, MBDiamond/1, MBSilver/1, CPU/1, CPUS/1, CPUD/1, OS/1, OSAlpha/1, OSBeta/1} ⊆ CLANG {efficiency/2, price/2, maxprice/2, clockrate/2, hdcapacity/2} ⊆ CLANG {pc-of-mb/2, mb-of-pc/2, mb-of-cpu/2, cpu-of-mb/2, pc-of-os/2, os-of-pc/2} ⊆

Attributes Relationships PC (efficiency) MB (efficiency) MB (price) CPUS (price)

part -of (PC,MB) part -of (PC,OS) part -of (MB,CPU) isa (MB) isa (CPU) isa (OS) gc1 gc2 gc3

prc2’

resc1

CLANG {∀X : PC(X ) → ∃11 Ax : efficiency (X , Ax )∧Ax = A ∨ Ax = B ∨ Ax = C.} ⊆ CKB {∀X : MB(X ) → ∃11 Ax : efficiency (X , Ax )∧Ax = A ∨ Ax = B ∨ Ax = C.} ⊆ CKB {∀X : MB(X ) → ∃11 Ax : price(X , Ax )∧ Ax ≥ 0 ∧ Ax ≤ 350.} ⊆ CKB {∀X : CPUS(X ) → ∃11 Ax : price(X , Ax ) ∧ Ax = 100.} ⊆ CKB {∀X : PC(X ) → ∃11 Y : MB(Y )∧ pc-of-mb(X , Y ).} ⊆ CKB {∀X : MB(X ) → ∃11 Y : PC(Y )∧ mb-of-pc(X , Y ).} ⊆ CKB {∀X : PC(X ) → ∃11 Y : OS(Y )∧ pc-of-os(X , Y )} ⊆ CKB {∀X : OS(X ) → ∃11 Y : PC(Y )∧ os-of-pc(X , Y ).} ⊆ CKB {∀X : MB(X ) → ∃12 Y : CPU (Y )∧ mb-of-cpu(X , Y )} ⊆ CKB {∀X : CPU (X ) → ∃11 Y : MB(Y )∧ cpu-of-mb(X , Y ).} ⊆ CKB {∀X : MB(X ) ↔ MBDiamond (X ) ∨ MBSilver (X ).} ⊆ CKB {∀X : MB(X ) → ¬MBDiamond (X ) ∨ ¬MBSilver (X ).} ⊆ CKB {∀X : CPU (X ) ↔ CPUD(X ) ∨ CPUS(X ).} ⊆ CKB {∀X : CPU (X ) → ¬CPUD(X ) ∨ ¬CPUS(X ).} ⊆ CKB {∀X : OS(X ) ↔ OSAlpha(X ) ∨ OSBeta(X ).} ⊆ CKB {∀X : OS(X ) → ¬OSAlpha(X ) ∨ ¬OSBeta(X ).} ⊆ CKB {∀X , Y : mb-of-cpu(X , Y ) ∧ MBDiamond (X ) ∧ CPUS(Y ) → false.} ⊆ CKB {∀X , Y : mb-of-cpu(X , Y ) ∧ MBSilver (X ) ∧ CPUD(Y ) → false.} ⊆ CKB {∀X , Y : PC(X ) ∧ OSAlpha(Y )∧ pc-of-os(X , Y ) → ∃11 U , V : MB(U ) ∧ CPUD(V )∧ pc-of-mb(X , U )∧ mb-of-cpu(U , V ).} ⊆ CKB {∀X : PC(X ) ∧ price(X , PCP )∧ pc-of-mb(X , Y )∧ pc-of-os (X , Z ) ∧ getcpus(Y , CPUs) → PCP =  c∈{Y ,Z }∪CPUs∧price(c,P ) P .} ⊆ CKB {∀X : PC(X ) ∧ price(X , PCP ) ∧ maxprice(X , PCMP ) → PCP ≤ PCMP .} ⊆ CKB

6.4 Logic-Based Knowledge Representation

63

Table 6.5 Example representation of user (customer) requirements (REQ). Modeling Facility

Example in FOL

User requirements

{PC(pc1 ).MBDiamond (mb1 ).} ⊆ REQ

Table 6.6 Example configuration (CONF) with completeness axioms (AX). Modeling Facility

Example in FOL

Components (CONF) Attributes (CONF)

{PC(pc1 ). MBDiamond (mb1 ). CPUD(cpu1 ). OSAlpha(os1 ).} ⊆ CONF {efficiency (pc1 , A). price(pc1 , 600). efficiency (mb1 , A). price(mb1 , 350). clockrate(cpu1 , fast ). price(cpu1 , 150). hdcapacity (os1 , 6). price(os1 , 100).} ⊆ CONF {pc-of-mb(pc1 , mb1 ). mb-of-pc(mb1 , pc1 ).} ⊆ CONF {mb-of-cpu(mb1 , cpu1 ). cpu-of-mb(cpu1 , mb1 ).} ⊆ CONF {pc-of-os(pc1 , os1 ). os-of-pc(os1 , pc1 ).} ⊆ CONF {PC(X ) → X = pc1 . MBDiamond (X ) → X = mb1 . …} ⊆ AX {efficiency (X , Y ) → (X = pc1 ∧ Y = A)∨ (X = mb1 ∧ Y = A) ∨ . . .} ⊆ AX {pc-of-mb(X , Y ) → (X = pc1 ∧ Y = mb1 ). . . .} ⊆ AX

Associations (CONF) Components (AX) Attributes (AX) Associations (AX)

knowledge representation, deductive databases, and logic programming (Brewka et al., 2011). ASP is a subset of FOL interpreted under stable-model semantics (Gelfond and Lifschitz, 1988). It is worth mentioning that configuration was one of the first real-world applications of ASP (see Soininen et al., 2001; Tiihonen et al., 2003, 2013). ASP programs are represented as a finite set of rules a ← b1 , . . . , bm , not c1 , . . . , not ck where a (head of the rule), bi and c j (body of the rule) are classical FOL atoms. In a rule, the atom a in the head is true if all literals of the body are true; that is, there is a derivation for each positive literal b1 , . . . , bm whereas none of the negative literals not c1 , . . . , not ck can be derived. A rule with an empty head (placeholder for false) is denoted as integrity constraint. For example, ← mbdiamond(X ), cpus(Y ), mb-o f -cpu(X , Y ). denotes the incompatibility between the component types MBDiamond and CPUS (see Figure 6.9). A rule with an empty body is denoted as fact; for example, mbsilver _domain(1..2) denotes the two facts mbsilver _domain(1) and mbsilver _ domain(2). Finally, weight constraints allow the definition of choices. For example, 1{cpu(X ) : cpu_domain(X )}2 denotes the fact that between 1 and 2 CPUs can be included in a configuration (cpu_domain describes the available CPU instances). The determination of configurations for ASP programs is based on two steps: (1) first order variables of the program are systematically replaced by the elements of the Herbrand universe (this process is also denoted as grounding (e.g., Gebser et al., 2009)) and (2) the resulting (variable-free) program is then fed into the ASP solver that determines stable models

64

CHAPTER 6 Configuration Knowledge Representation and Reasoning

(answer sets), minimal models of the ASP program (Giunchiglia et al., 2006). The ASP representation of the configuration model depicted in Figure 6.9 is shown in Table 6.7. For reasons of readability we omitted the specification of attribute domains on all levels of the generalization hierarchy. For example, the specification of the possible values of the clockrate attribute (component type cpu) can be implemented as follows: 1{clockrate(C,A): clockrate_domain(A)}1 :- cpu(C). clockrate_domain(slow;medium;fast). ASP representations of customer requirements and a configuration result are shown in Table 6.8.

Table 6.7 Example formalizations of the PC configuration model shown in Figure 6.9 defined in clingo (see potassco.sourceforge.net). Concept

ASP Representation

Components (instances)

pc_domain(1). mbsilver_domain(2). mbdiamond_domain(3). cpud_domain(4). cpud_domain(5). cpus_domain(6). cpus_domain(7). osalpha_domain(8). osbeta_domain(9). mb_domain(X) :- mbsilver_domain(X). mb_domain(X) :- mbdiamond_domain(X). cpu_domain(X) :- cpud_domain(X). cpu_domain(X) :- cpus_domain(X). os_domain(X) :- osalpha_domain(X). os_domain(X) :- osbeta_domain(X). mbsilver(X) :- component(X), mbsilver_domain(X). mbdiamond(X) :- component(X), mbdiamond_domain(X). mb(X) :- component(X), mb_domain(X). cpus(X) :component(X), cpus_domain(X). cpud(X) :- component(X), cpud_domain(X). cpu(X) :component(X), cpu_domain(X). osalpha(X) :- component(X), osalpha_domain(X). osbeta(X) :- component(X), osbeta_domain(X). os(X) :- component(X), os_domain(X). efficiency(X,b) :- mbsilver(X). efficiency(X,a) :- mbdiamond(X). price(X,250) :- mbsilver(X). price(X,350) :- mbdiamond(X). clockrate(X,medium) :- cpus(X). clockrate(X,fast) :cpud(X). price(X,100) :- cpus(X). price(X,150) :- cpud(X). hdcapacity(X,6) :osalpha(X). hdcapacity(X,13) :- osbeta(X). price(X,100) :- osalpha(X). price(X,500) :osbeta(X). mb(X) :- mbsilver(X). mb(X) :- mbdiamond(X). cpu(X) :- cpus(X). cpu(X) :- cpud(X). os(X) :- osalpha(X). os(X) :- osbeta(X). 1 { mb_of_cpu(X,Y) : cpu_domain(Y) } 2 :- mb(X). 1 { pc_of_mb(X,Y) : mb_domain(Y) } 1 :- pc(X). 1 { pc_of_os(X,Y) : os_domain(Y) } 1 :- pc(X). cpu_of_mb(Y,X) :- mb_of_cpu(X,Y). mb_of_pc(X,Y) :- pc_of_mb(Y,X). os_of_pc(X,Y) :pc_of_os(Y,X). component(Y) :- mb_of_cpu(X,Y). component(Y) :- pc_of_mb(X,Y). component(Y) :pc_of_os(X,Y). :- mbdiamond(X), cpus(Y), mb_of_cpu(X,Y). :- mbsilver(X), cpud(Y), mb_of_cpu(X,Y). :- osalpha(X), not cpud(C), pc_of_os(P,X), pc_of_mb(P,M), mb_of_cpu(M,C). pcprice(A,P) :- P = #sum [price(C,PR) = PR], pc(A). :- pc(X), maxprice(X,P), pcprice(X,Q), Q > P.

Domain generalizations Component types

Attribute domains

Generalization hierarchies Part of relationships Symmetry properties Component generation gc1 gc2 gc3 prc2’ resc1

6.4 Logic-Based Knowledge Representation

65

Table 6.8 Example configuration result calculated by clingo (see potassco.sourceforge.net). Concept

ASP Representation

Customer requirements Configuration (result)

pc(1). maxprice(1,2500). efficiency(1,b). pc(1), maxprice(1,2500), efficiency(1,b), pc_of_mb(1,2), pc_of_os(1,9), pcprice(1,850), mbsilver(2), mb(2), efficiency(2,b), price(2,250), mb_of_cpu(2,7), mb_of_pc(2,1), osbeta(9), os(9), hdcapacity(9,13), price(9,500), os_of_pc(9,1), cpus(7), cpu(7), clockrate(7,medium), price(7,100), cpu_of_mb(7,2)

Description Logics Description Logics (DL; Baader et al., 2003) is a popular knowledge representation formalism in the context of the Semantic Web. DL can be used for configuration knowledge representation, especially for the design of component type hierarchies (ontologies) and for coherence analysis. A Description Logic knowledge base consists of two major elements: the T Box introduces concepts, relationships, and constraints of the (product) domain, the ABox contains assertions about individuals. Thus, the TBox can be used to represent the configuration model and the ABox the resulting configuration. Description Logics have been successfully applied for the development of configuration systems—for a detailed related discussion refer to Hotz et al. (2006) and McGuinness and Wright (1998). Felfernig et al. (2003) have analyzed the applicability of Description Logics for the representation of configuration knowledge. DL can be used to represent configuration knowledge, however, some specific constraint types are supported in a restricted fashion. For example, no aggregation functions are provided and constraints on complex connection structures (via ports) cannot be defined due to the lower (but decidable) expressiveness of many DL dialects. Furthermore, because there is no standard inference method that provides automatic instantiation, the DL-Reasoner has to be included in an architecture that creates individuals from outside. This is needed because of the incremental aspects of configuration processes (see Buchheit et al., 1995; Hotz and Neumann, 2005; Stumptner, 1997). Beside this analysis, Felfernig et al. (2003) also introduce a formal definition of a configuration problem and its solution in Description Logic and show the equivalence of this definition with a predicate logic-based definition.

Hybrid Configuration Hybrid configuration exploits several representation and reasoning mechanisms (Stumptner, 1997). Typically, there is an ontology-like (DL-based) representation (Baader et al., 2003) for representing components, their compositional relations, and attributes. Additionally, constraints are used for representing n-ary relations between components and for computing and inferring attribute values. The configuration process combines the related inference mechanisms, ontology inference services, and constraint propagation in a cyclic manner. Additionally, procedural knowledge (Hotz et al., 2006; McDermott, 1982) can be used for describing the order of configuration steps of the configuration

66

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Table 6.9 Criteria for comparing configuration knowledge representations. id

Criteria description

C1 C2 C3 C4 C5 C6 C7 C8 C9

Standard graphical modeling concepts? Component-oriented modeling? Automated consistency maintenance? Modularization concepts available? Support of easy knowledge base evolution and maintenance? Model-based knowledge representation? Efficient reasoning? Able to solve generative problem settings? Able to provide explanations?

process. A detailed description of a configuration environment based on a hybrid configuration approach is given in Hotz and Günter (2014)19 .

6.5 Comparison of Knowledge Representations We now compare the configuration knowledge representations that have been discussed within the scope of this chapter (RBS = rule-based systems, SCSP = static constraint satisfaction, DCSP = dynamic constraint satisfaction, GCSP = generative constraint satisfaction, SAT = SAT solving, FM = feature models, UML = UML configuration models, DL = Description Logics, ASP = Answer Set Programming, HB = hybrid configuration). We will first provide an overview of the relevant criteria (see Table 6.9) and then discuss the evaluation results (see Table 6.10).

6.5.1 Evaluation Criteria The evaluation criteria are summarized in Table 6.9. The first evaluation criterion (C1) is related to the availability of standard graphical modeling concepts that help (1) to improve the understandability of configuration knowledge and (2) to increase the efficiency of configuration knowledge base development and maintenance processes. Criterion C2 is related to the question whether the knowledge representation formalism supports configuration knowledge design on the basis of concepts near to real-world entities (i.e., component types, attributes, relationships, generalization hierarchies, relevant constraint types, etc.). C3 raises the question whether mechanisms for automated consistency maintenance are available; for example, if a new constraint (or concept) is added to the knowledge base, it should be immediately clear, whether inconsistencies are introduced or not. Criterion C4 is related to the availability of modularization and structuring concepts for knowledge bases; for example, in which way is it possible to organize (group) the constraints inside a knowledge base. 19 Chapter

24.

6.5 Comparison of Knowledge Representations

67

Table 6.10 Evaluation of representations (RBS = rule-based systems, SCSP = static CSP, DCSP = dynamic CSP, GCSP = generative CSP, SAT = Sat Solving, FM = feature models, UML = UML configuration models, DL = Description Logics, ASP = Answer Set Programming, √ HB = hybrid configuration). = good support, ≈ = some support, and – = no support. id C1 C2 C3 C4 C5 C6 C7 C8 C9

RBS – – –

SCSP

DCSP

GCSP

– –

– –

√

– –

≈

≈

≈ √

≈

– –

≈ √ √

≈ √ √

≈ √ √

≈ ≈

–

–

≈ √ √ √ √

≈ √

–

√

–

√

–

SAT

–

–

≈

FM

UML

DL

ASP

HB

√

√ √

≈ √

√

–

≈ √

√

–

≈ √

≈ √

≈ √

≈ √

≈ √

≈ √

≈ √

≈ √

– – –

– – –

≈

≈ ≈ √

≈ √ √

– – –

–

√

C5 evaluates the quality of support of knowledge base evolution and maintenance, for example, in terms of intelligent navigation support in complex knowledge spaces. C6 evaluates whether the underlying knowledge representation is model-based. C7 poses the question whether the type of knowledge representation allows efficient reasoning. C8 evaluates whether a generative configuration scenario can be implemented; that is, whether components and related constraints can be generated on-demand (see Subsection 6.2.2). C9 is related to the question whether the generation of explanations can be supported.

6.5.2 Comparison of Knowledge Representations On the basis of the evaluation criteria summarized in Table 6.9 we are able to discuss the advantages and disadvantages of the knowledge representation formalisms presented in this chapter (see Table 6.10). √ These formalisms are evaluated on the basis of criteria C1−C9 on a rating scale of ( = good support, ≈ = some support, and – = no support). Standard graphical knowledge representations (C1) are primarily provided by feature models (Benavides et al., 2010) and component-oriented modeling approaches such as the Unified Modeling Language (Felfernig, 2007; Felfernig et al., 2000a). Component-oriented modeling (C2) is supported by GCSPs (Stumptner et al., 1998) and modeling approaches in the line of UML, Description Logics (Baader et al., 2003), Answer Set Programming (ASP; Brewka et al., 2011), and Hybrid Configuration (HB; Stumptner, 1997). Automated consistency maintenance (C3) can easily be implemented on top of most of the given knowledge representations (Felfernig et al., 2004, 2012). FM and UML artifacts have to be connected with a corresponding reasoning support. Intelligent modularization (C4) in GCSP, UML, DL, and HB is supported in terms of a component (class) dependent definition of domain constraints. With the exception of RBS all representations allow an arbitrary ordering (organization) of the constraints in the knowledge base without changing its underlying semantics; RBS

68

CHAPTER 6 Configuration Knowledge Representation and Reasoning

often also dispose of concepts for structured rule representation. Graphical UML modeling supports the inclusion of advanced modularization concepts such as packaging and diagram contextualization (Felfernig et al., 2000b; Felfernig and Zanker, 2000). Techniques for easy knowledge base evolution and maintenance (C5) are not primarily depending on the knowledge representation itself but more on additional meta-functionalities that support intuitive knowledge navigation and adaptation; nearly all representation formalisms can be equipped with such a functionality (Felfernig et al., 2013b). RBS have serious maintenance problems due to the dependence of product domain and problem solving knowledge. With the exception of RBS, all other representations follow a model-based paradigm (C6) that supports a clear separation of domain and problem-solving knowledge. RBS and constraint satisfaction algorithms have proven to support efficient problem solving on an industrial scale. For this reason, these approaches are evaluated better with regard to performance (C7). GCSP allows the determination of solutions for generative configuration problems; ASP and HB are also able to provide such functionalities (C8). With the exception of FM and UML, all approaches provide basic support for explanations (as to why a configuration could (not) be found). Dependencies between domain and problem solving knowledge in RBS and encodings in SAT (see Subsection 6.2.1) make these approaches less accessible for explanation techniques.

6.6 Conclusion In this chapter we provided an overview of different configuration knowledge representation and reasoning techniques. These techniques were discussed on the basis of a timeline ranging from the rulebased configuration system R1/XCON implemented in the late 1970’s via different types of constraint representations and constraint reasoning approaches through to advanced knowledge representation and reasoning approaches that are applied nowadays for the definition and solution of configuration tasks.

Acknowledgments The work presented in this chapter was partially funded by the Austrian research promotion agency (grant numbers: 827587 and 825071).

References Amilhastre, J., Fargier, H., Marquis, P., 2002. Consistency restoration and explanations in dynamic CSPs application to configuration. Artificial Intelligence 135 (1–2), 199–234. Andersen, H., Hadzic, T., Pisinger, D., 2010. Interactive cost configuration over decision diagrams. Journal of Artificial Intelligence Research 37, 99–139. Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F. (Eds.), 2003. The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press, New York, NY. Bacchus, F., vanBeek, P., 1998. On the conversion between non-binary and binary constraint satisfaction problems. In: 15th National Conference on Artificial Intelligence (AAAI’98). Madison, Wisconsin, pp. 311–318.

References

69

Batory, D., 2005. Feature models, grammars, and propositional formulas. In: Obbink, H., Pohl, K. (Eds.), Software Product Lines Conference. Lecture Notes in Computer Science, vol. 3714. Springer, Rennes, France, pp. 7–20. Benavides, D., Segura, S., Ruiz-Cortés, A., 2010. Automated analysis of feature models 20 years later: a literature review. Information Systems 35 (6), 615–636. Booch, G., Rumbaugh, J., Jacobson, I., 2005. Unified Modeling Language User Guide, second ed. AddisonWesley, Reading, MA. Bowen, J., Bahler, D., 1991. Conditional existence of variables in generalized constraint networks. In: 9th National Conference on Artificial Intelligence (AAAI-91). Anaheim, California, pp. 215–220. Brailsford, S., Potts, C., Smith, B., 1999. Constraint satisfaction problems: algorithms and applications. European Journal of Operational Research 199 (3), 557–581. Brewka, G., Eiter, T., Truszczy´nski, M., 2011. Answer set programming at a glance. Communications of the ACM 54 (12), 92–103. Buchheit, M., Klein, R., Nutt, W., 1995. Constructive Problem Solving: A Model Construction Approach Towards Configuration, Deutsches Forschungszentrum für Künstliche Intelligenz, Saarbrücken (TM-95-01). Claessen, K., Een, N., Sheeran, M., Sörensson, N., 2008. SAT-solving in practice. In: 9th International Workshop on Discrete Event Systems. Göteborg, Sweden, pp. 61–67. Czarnecki, K., Helsen, S., Eisenecker, U., 2005. Formalizing cardinality-based feature models and their specialization. SoftwareProcess: Improvement and Practice 10 (1), 7–29. Falkner, A., Haselböck, A., 2013. Challenges of knowledge evolution in practice. AI Communications 26 (1), 3–14. Falkner, A., Schreiner, H., 2014. SIEMENS: configuration and reconfiguration in industry. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 199–210 (Chapter 16). Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Faltings, B., Weigel, R., 1994. Constraint-based knowledge representation for configuration systems. Tech. Rep. TR-94/59, Ecole Polytechnique Fédérale de Lausanne (EPFL), Switzerland. Felfernig, A., 2007. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management 54 (1), 41–56. Felfernig, A., Burke, R., 2008. Constraint-based recommender systems: technologies and research issues. In: ACM International Conference on Electronic Commerce (ICEC08). Innsbruck, Austria, pp. 17–26. Felfernig, A., Zanker, M., 2000. Diagrammatic acquisition of functional knowledge for product configuration systems with the unified modeling language. In: Proceedings of the First International Conference on Theory and Application of Diagrams (Diagrams ’00). Lecture Notes in Computer Science, vol. 1889. Springer-Verlag, London, UK, pp. 361–375. Felfernig, A., Friedrich, G.E., Jannach, D., 2000a. UML as domain specific language for the construction of knowledge-based configuration systems. International Journal of Software Engineering and Knowledge Engineering 10 (4), 449–469. Felfernig, A., Jannach, D., Zanker, M., 2000b. Contextual diagrams as structuring mechanisms for designing configuration knowledge bases in UML. In: 3rd International Conference on the Unified Modeling Language (UML2000). Lecture Notes in Computer Science, Vol. 1939. Springer, York, UK, pp. 240–254. Felfernig, A., Friedrich, G., Jannach, D., 2001. Conceptual modeling for configuration of mass-customizable products. Artificial Intelligence in Engineering 15 (2), 165–176. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., Zanker, M., 2003. Configuration knowledge representations for semantic web applications. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 17 (1), 31–50. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., 2004. Consistency-based diagnosis of configuration knowledge bases. Artificial Intelligence 152 (2), 213–234.

70

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Felfernig, A., Schubert, M., Zehentner, C., 2012. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 26 (1), 53–62. Felfernig, A., Benavides, D., Galindo, J., Reinfrank, F., 2013a. Towards anomaly explanation in feature models. In: Workshop on Configuration. Vienna, Austria, pp. 117–124. Felfernig, A., Reiterer, S., Stettinger, M., Reinfrank, F., Jeran, M., Ninaus, G., 2013b. Recommender systems for configuration knowledge engineering. In: Workshop on Configuration. Vienna, Austria, pp. 51–54. Fleischanderl, G., Friedrich, G.E., Haselböck, A., Schreiner, H., Stumptner, M., 1998. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems 13 (4), 59–68. Freuder, E., 1997. In pursuit of the holy grail. Constraints 2 (1), 57–61. Friedrich, G., Jannach, D., Stumptner, M., Zanker, M., 2014. Knowledge engineering for configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 139–155 (Chapter 11). Gebser, M., Kaminski, R., Ostrowski, M., Schaub, T., Thiele, S., 2009. On the input language of ASP grounder Gringo. In: Erdem, E., Lin, F., Schaub, T. (Eds.), Proceedings of the 10th International Conference on Logic Programming and Nonmonotonic Reasoning. Lecture Notes in Computer Science, Vol. 5373. Springer, Potsdam, Germany, pp. 502–508. Gelfond, M., Lifschitz, V., 1988. The stable model semantics for logic programming. In: Kowalkowski, R.A., Bowen, K.A. (Eds.), Logic Programming: Proceedings of the 5th International Conference and Symposium. Seattle, WA, pp. 1070–1080. Giunchiglia, E., Lierler, Y., Maratea, M., 2006. Answer set programming based on propositional satisfiability. Journal of Automated Reasoning 36 (4), 345–377. Gomes, C., Kautz, H., Sabharwal, A., Selman, B., 2008. Satisfiability solvers. In: Handbook of Knowledge Representation. Foundations of Artificial Intelligence, vol. 3. Elsevier, New York, NY, pp. 89–134 (Chapter 2). Günter, A., Kühn, C., 1999. Knowledge-Based Configuration - Survey and Future Directions. In: Puppe, F. (Ed.), XPS-99: knowledge based systems, proceedings 5th biannual german conference on knowledge based systems. Lecture Notes in Artificial Intelligence, Vol. 1570. Springer, Würzburg. Hotz, L., Günter, A., 2014. KONWERK. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledgebased Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 281–295 (Chapter 24). Hotz, L., Neumann, B., 2005. Scene Interpretation as a Configuration Task. Künstliche Intelligenz 3, 59–65. Hotz, L., Wolter, K., 2014. Smarthome Configuration Model. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 121–135 (Chapter 10). Hotz, L., Wolter, K., Krebs, T., Deelstra, S., Sinnema, M., Nijhuis, J., MacGregor, J., 2006. Configuration in Industrial Product Families - The ConIPF Methodology. IOS Press, Berlin. Jannach, D., Zanker, M., Felfernig, A., Friedrich, G., 2010. Recommender Systems: An Introduction. Cambridge University Press, MA. Janota, M., 2008. Do SAT solvers make good configurators? In: First Workshop on Analyses of Software Product Lines (ASPL08) of 12th International Software Product Lines Conference (SPLC08). Limerick, Ireland, pp. 10–14. Janota, M., Botterweck, G., Grigore, R., Marques-Silva, J., 2010. How to complete an interactive configuration process? In: 36th Conference on Current Trends in Theory and Practice of Computer Science (SOFSEM 2010). ˚ Mlýn, Czech Republic, pp. 528–539. Lecture Notes in Computer Science, vol. 5901. Springer, Špindleruuv Jüngst, W., Heinrich, M., 1998. Using resource balancing to configure modular systems. IEEE Intelligent Systems 13 (4), 50–58.

References

71

Junker, U., 2004. QUICKXPLAIN: preferred explanations and relaxations for over-constrained problems. In: McGuinness, D.L., Ferguson, G. (Eds.), 19th Intl. Conference on Artifical Intelligence (AAAI’04). AAAI Press, pp. 167–172. Junker, U., 2006. Configuration. In: Rossi, F., vanBeek, P., Walsh, T. (Eds.), Handbook of Constraint Programming. Foundations of Artificial Intelligence, vol. 2. Elsevier, New York, NY, pp. 837–873. Junker, U., Mailharro, D., 2003. The logic of ILOG (J)Configurator: Combining constraint programming with a description logic. In: 18th International Joint Conference on Artificial Intelligence (IJCAI-03), Configuration Workshop. Acapulco, Mexico, pp. 13–20. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S., 1990. Feature-Oriented Domain Analysis Feasibility Study (FODA). Tech. Rep. CMU/SEI-90-TR-021, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA. Kiziltan, Z., Hnich, B., 2001. Symmetry breaking in a rack configuration problem. In: Seventeenth International Joint Conference on Artificial Intelligence (IJCAI-2001), Workshop on Modelling and Solving Problems with Constraints. Seattle, WA, pp. 1–6. Leitner, G., Felfernig, A., Blazek, P., Reinfrank, F., Ninaus, G., 2014. User interfaces for configuration environments. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 89–106 (Chapter 8). Li, B., Chen, L., Huang, Z., Zhong, Y., 2006. Product configuration optimization using a multiobjective genetic algorithm. International Journal of Advanced Manufacturing Technology 30 (1–2), 20–29. Mackworth, A., 1977. Consistency in networks of relations. Artificial Intelligence 8 (1), 99–118. Mailharro, D., 1998. A classification and constraint-based framework for configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (4), 383–397. McDermott, J., 1982. R1: a rule-based configurer of computer systems. Artificial Intelligence 19 (1), 39–88. McGuinness, D., Wright, J., 1998. An industrial-strength description logic-based configurator platform. Intelligent Systems and their Applications, IEEE 13 (4), 69–77. Mittal, S., Falkenhainer, B., 1990. Dynamic constraint satisfaction problems. In: Proceedings of the eighth national conference on artificial intelligence (AAAI-90). Boston, MA, pp. 25–32 Aug. Mittal, S., Frayman, F., 1989. Towards a generic model of configuration tasks. 11th International Joint Conference on Artificial Intelligence (IJCAI-89). Detroit, Michigan, vol. 2 pp. 1395–1401. Neumann, B., 1988. Configuration expert systems: a case study and tutorial. In: Bunke, H.O. (Ed.), Proc. 1988 SGAICO Conference on Artificial Intelligence in Manufacturing, Assembly, and Robotics. Oldenbourg, Munich, pp. 27–68. Pinedo, M., 2012. Scheduling: Theory, Algorithms, and Systems, fourth ed. Springer, New York, NY. Pitiot, P., Aldanondo, M., Vareilles, E., Gaborit, P., Djefel, M.S.C., 2013. Concurrent product configuration and process planning, towards an approach combining interactivity and optimality. International Journal of Production Research 51 (2), 524–541. Puget, J.-F., Albert, P., 1991. PECOS: programmation par contraintes orientée objets. Génie logiciel et systèmes experts (GLSE) 23, 100–105. Reiter, R., 1987. A theory of diagnosis from first principles. Artificial Intelligence 32 (1), 57–95. Rossi, F., vanBeek, P., Walsh, T. (Eds.), 2006. Handbook of Constraint Programming. Foundations of Artificial Intelligence. Elsevier, New York, NY. Russel, S., Norvig, P., 2003. Artificial Intelligence – A Modern Approach, 2nd Edition. Prentice Hall, Upper Saddle River, NJ. Sabin, D., Weigel, R., 1998. Product configuration frameworks – a survey. IEEE Intelligent Systems 13 (4), 42–49. Schröder, C., Möller, R., Lutz, C., 1996. A partial logical reconstruction of PLAKON/KONWERK. In: Baader, F., Bürckert, H.-J., Günther, A., Nutt, W. (Eds.), Proceedings of the Workshop on Knowledge Representation and Configuration WRKP’96. No. D-96-04 in DFKI Documents, pp. 55–64.

72

CHAPTER 6 Configuration Knowledge Representation and Reasoning

Sinz, C., Haag, A., Narodytska, N., Walsh, T., Gelle, E., Sabin, M., Junker, U., O’Sullivan, B., Rabiser, R., Dhungana, D., Grünbacher, P., Lehner, K., Federspiel, C., Naus, D., 2007. Configuration. IEEE Intelligent Systems 22 (1), 78–90. Soininen, T., Tiihonen, J., Männistö, T., Sulonen, R., 1998. Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (4), 357–372. 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. Soloway, E., Bachant, J., Jensen, K., 1987. Assessing the maintainability of XCON-in-RIME: coping with the problem of very large rule-bases. In: Proceedings of the Sixth National Conference on Artificial Intelligence (AAAI-87). Seattle, Washington, pp. 824–829 July 13–17. Stumptner, M., 1997. An overview of knowledge-based configuration. AI Communications 10 (2), 111–126. Stumptner, M., Friedrich, G., Haselböck, A., 1998. Generative constraint-based configuration of large technical systems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (4), 307–320. Terashima-Marin, H., Ross, P., Valenzuela-Rendon, M., 2008. Hyper-heuristics for the dynamic variable ordering in constraint satisfaction problems. In: Genetic and Evolutionary Computation Conference (GECCO’08). Atlanta, Georgia, pp. 571–578. Tiihonen, J., Soininen, T., Niemelä, I., Sulonen, R., 2003. 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, p. 10 (Paper number: 1290). Tiihonen, J., Heiskala, M., Anderson, A., Soininen, T., 2013. WeCoTin – A practical logic-based sales configurator. AI Communications 26 (1), 99–131. Tsang, E., 1993. Foundations of Constraint Satisfaction. Academic Press, London, San Diego, New York. Warmer, J., Kleppe, A., 2003. The Object Constraint Language: Getting Your Models Ready for MDA, second ed. Addison-Wesley Longman Publishing, Boston, MA.

CHAPTER

Conflict Detection and Diagnosis in Configuration

7

Alexander Felfernig* , Stefan Reiterer† , Florian Reinfrank* , Gerald Ninaus* and Michael Jeran* * Graz

University of Technology, Graz, Austria † SelectionArts, Graz, Austria

Abstract: The widespread industrial application of configuration technologies triggers an increasing demand for intelligent techniques that efficiently support anomaly management operations for configuration knowledge bases. Examples of such operations are the testing and debugging of faulty knowledge bases (see Chapter 11) and the detection of redundancies in configuration knowledge bases (see Chapter 12). The goal of this chapter is to discuss techniques and algorithms that form the technological basis for the aforementioned anomaly management operations.

7.1 Introduction Anomalies can be characterized as parts of a knowledge base that conform to a defined pattern of unintended structures (see also Chandola et al., 2009). Anomaly management operations presented in this book are the automated testing and debugging of configuration knowledge bases (see Friedrich et al., 20141 ) and the automated detection of redundancies in configuration knowledge bases (see Felfernig et al., 20142 ). Anomaly management operations are very important since configuration knowledge bases are often complex and subject to frequent changes (Barker et al., 1989; Fleischanderl et al., 1998). The foundations for anomaly management are conflict detection and diagnosis algorithms that help to detect (1) minimal subsets of the knowledge base that are responsible for a faulty behavior (Felfernig et al., 2004, 2012, 2013; Junker, 2004) and (2) maximal subsets of the knowledge base that are redundancy-free (Felfernig et al., 2011). More precisely, conflict detection algorithms are able to determine minimal sets of constraints that are inconsistent; that is, do not allow the determination of a solution (configuration). In addition, diagnosis algorithms can determine minimal sets of constraints in the configuration knowledge base that have to be deleted or adapted such that the remaining set of constraints is consistent (see Friedrich et al., 2014); that is, a solution can be determined. Typically, diagnoses are determined from a given set of (minimal) conflicts and vice versa, minimal conflicts can be determined on the basis of a given set of (minimal) diagnoses (see Section 7.4). The major focus of this chapter is to provide an introduction to some of the existing conflict detection and diagnosis techniques that are the foundation for the aforementioned anomaly management 1 Chapter

2 Chapter

11. 12.

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00007-4 © 2014 Elsevier Inc. All rights reserved.

73

74

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

operations. The remainder of this chapter is organized as follows. In Section 7.2, we introduce the working example used in this chapter, a simplified version of the example configuration knowledge base introduced in Hotz et al. (2014).3 We discuss selected conflict detection algorithms in Section 7.3 and the corresponding diagnosis algorithms in Section 7.4. On the basis of the results of a performance analysis, we discuss the advantages and disadvantages of the presented conflict detection and diagnosis algorithms. Section 7.5 concludes this chapter.

7.2 Example We introduce a working example that is based on the configuration knowledge base introduced in Hotz et al. (2014). For the following discussions we introduce the configuration knowledge base (C K B ) of a fragment of a personal computer (PC), which consists of the component types MB (motherboard) and CPU (central processing unit) and their specific subtypes {MBSilver, MBDiamond} and {CPUS, CPUD}. The following personal computer (PC) configuration knowledge base (configuration model) is inconsistent, meaning that it does not allow the calculation of a solution (configuration). Such situations often occur as a result of maintenance operations in a knowledge base where, for example, conflicts are introduced due to the insertion of new elements or due to the adaptation of existing ones. In our working example we assume that constraint c2 (CPUS requires MBSilver) has been added by the knowledge engineer in order to replace the faulty constraint c1 (CPUS requires MBDiamond). Unfortunately, the knowledge engineer inserted c2 without deleting c1 . Our example also assumes that a constraint c5 (instances of the component type CPUD should not be part of any configuration) was introduced earlier for testing purpose with no intent to have it pertaining to the configuration model. However the knowledge engineer forgot to disable it after testing the model. Constraint c3 states that an MBSilver must not be combined with a CPUD and constraint c4 states that an MBDiamond must not be combined with a CPUS. CK B = { cα : ∀X : M B(X ) → ∃11 Y : cpu-of-mb(Y, X).

cβ : ∀X : C PU (X ) → ∃11 Y : mb-of-cpu(Y, X). cγ : ∀X : M B(X ) ↔ M B Silver (X ) ∨ M B Diamond(X ).

cδ : ∀X : ¬M B Silver (X ) ∨ ¬M B Diamond(X ). cǫ : ∀X : C PU (X ) ↔ C PU D(X ) ∨ C PU S(X ). cφ : ∀X , Y : cpu-of-mb (X,Y) ↔ mb-of-cpu (Y,X). cι : ∀X : ¬C PU D(X ) ∨ ¬C PU S(X ). c1 : ∀X , Y : cpu-of-mb (Y, X) ∧ C PU S(Y ) → M B Diamond(X ). c2 : ∀X , Y : cpu-of-mb (Y , X ) ∧ C PU S(Y ) → M B Silver (X ). c3 : ∀X , Y : cpu-of-mb (Y , X ) ∧ C PU D(Y ) ∧ M B Silver (X ) → f alse. c4 : ∀X , Y : cpu-of-mb (Y , X ) ∧ C PU S(Y ) ∧ M B Diamond(X ) → f alse. c5 : ∀X : C PU D(X ) → f alse. } 3 Chapter

6.

7.3 Determining Minimal Conflict Sets

75

We will now start with a discussion of algorithms that focus on conflict detection and then show how to exploit identified minimal conflict sets in order to determine corresponding diagnoses. Note that conflict detection and diagnosis algorithms discussed hereafter are a basis for the concepts explained in Friedrich et al. (2014)4 and Felfernig et al. (2014).5

7.3 Determining Minimal Conflict Sets Before discussing basic conflict detection algorithms useful for (but not limited to) configuration scenarios, we introduce the definition of a conflict (conflict set) in the context of an inconsistent configuration knowledge base. Definition (Minimal Conflict Set). A conflict set CS = {ca , cb , . . ., cz } is a subset of C such that inconsistent (B ∪ C S). AC = B ∪ C represents the set of all constraints in the knowledge base (AC = {c1 , c2 , . . ., cn }), B represents the background knowledge (no conflict elements are assumed to be included in B), and C represents the set of constraints subject of conflict search. A conflict set CS is minimal if there does not exist a C S ′ ⊂ C S that has the conflict property. Note that if we want to analyze the whole knowledge base (taking into account the complete set of constraints in conflict set search), we simply have to define C = AC and, as a consequence, B = ∅. In our working example we are able to identify the following minimal conflict sets: C S1 = {c1 , c4 , c5 } and C S2 = {c1 , c2 , c5 }. These sets do not allow the determination of a solution; inconsistent ({c1 , c4 , c5 }∪ B) and inconsistent ({c1 , c2 , c5 }∪ B). C S1 and C S2 are minimal since none of their subsets fulfills the conflict set property. Each minimal conflict set (conflict) can simply be resolved by deleting one of its elements. This approach is used by some of the diagnosis algorithms discussed in Section 7.4. In the remainder of this section we introduce and evaluate two basic conflict detection algorithms: SIMPLECONFLICTDETECTION and QUICKXPLAIN.

7.3.1 Simple Conflict Detection The first approach to the determination of minimal conflict sets is SIMPLECONFLICTDETECTION (see Algorithm 7.1). Conforming with the introduced definition of a conflict set, the algorithm focuses the search for a minimal conflict by explicitly specifying the set of constraints C ⊆ AC that might induce a conflict. Note that SIMPLECONFLICTDETECTION determines exactly one conflict set per computation. In order to identify all minimal conflicts in C, this algorithm has to be combined with a HSDAG-based diagnosis algorithm (see Section 7.4). The set CS collects all relevant elements (constraints) of the minimal conflict. If the deletion of all constraints of C does not allow the determination of a solution (inconsistent(B)) or AC (B ∪ C) itself is consistent, there is no need for searching for a conflict (the empty set ∅ is returned). In all other cases, the algorithm tries to identify a minimal conflict. In order to achieve this goal, elements ci of C are extracted and used to figure out whether they are triggering a conflict. If such an element has been identified, it is stored in the set C S, which collects the set of elements contributing to the conflict. 4 Chapter

5 Chapter

11. 12.

76

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

In order to demonstrate the functionality of SIMPLECONFLICTDETECTION, the basic steps of this algorithm are shown in Table 7.1. For this example (see also Figure 7.1) we take the constraints of our domain description (DD) and assume that C = {c1 , c2 , c3 , c4 , c5 } and AC = {cα , cβ , cγ , cδ , cǫ , cφ , cι , c1 , c2 , c3 , c4 , c5 } (B = {cα , cβ , cγ , cδ , cǫ , cφ , cι }). The inner loop is responsible for detecting individual elements that participate in the conflict, the outer loop is responsible for checking whether the generated set C S is already inconsistent (i.e., a minimal conflict set could be found). Algorithm Analysis. If a minimal conflict set can be determined (AC − C consistent and AC inconsistent), SIMPLECONFLICTDETECTION needs O(2) additional consistency checks in the best case (a constraint ca that represents a singleton conflict and is located at the first position of the constraint list C).

Table 7.1 Example of the application of SIMPLECONFLICTDETECTION. CS = {c1 , c4 , c5 } is returned as minimal conflict set (CS) for C = {c5 , c4 , c3 , c2 , c1 } and B = {cα , cβ , cγ , cδ , cǫ , cφ , cι }. Step

CS

c



1 2 3 4 5 6 7 8 9

∅ ∅ ∅ ∅ ∅ {c1 } {c1 } {c1 , c4 } {c1 , c4 , c5 }

c5 c4 c3 c2 c1 c5 c4 c5

{c5 } {c5 , c4 } {c5 , c4 , c3 } {c5 , c4 , c3 , c2 } {c5 , c4 , c3 , c2 , c1 } {c1 , c5 } {c1 , c5 , c4 } {c1 , c4 , c5 }

–

–

7.3 Determining Minimal Conflict Sets

77

FIGURE 7.1 A conflict set CS is a subset of C (AC = C ∪B), which is inconsistent with B. CS is minimal if no subset of CS fulfills the conflict set property. In this context, B is the background knowledge that includes all constraints considered correct. An example conflict set is CS1 = {c1 , c4 , c5 }.

In the worst case, each element of C is also part of the minimal conflict—in this case, O additional consistency checks are needed.



(n×(n+1)) 2

+n



7.3.2 QuickXPlain A more efficient approach to the determination of minimal conflict sets is QUICKXPLAIN introduced by (Junker, 2004; see Algorithm 7.2). This algorithm is based on the concept of divide and conquer: each time it detects that the first half of a constraint set C is already inconsistent, the second half of the constraint set is omitted (not further taken into account when determining the conflict). This is an efficient way to get rid of constraints that do not participate in the conflict.

78

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

Table 7.2 Example of QUICKXPLAIN: Ŵ = {cα , cβ , cγ , cδ , cǫ , cφ , cι } is the (original) background knowledge and CS = {c1 , c4 , c5 } is the returned conflict set. The sequence of the different QX activations is depicted in Figure 7.2. Step

D

C

B

C1

C2

Return

1 2 3 4 5 6 7 8 9

∅ {c4 , c5 } {c3 } {c2 } {c1 } {c1 } {c1 } {c5 } {c4 }

{c1 , . . ., c5 } {c1 , c2 , c3 } {c1 , c2 } {c1 } {c2 } {c3 } {c4 , c5 } {c4 } {c5 }

Ŵ Ŵ ∪ {c4 , c5 } Ŵ ∪ {c3 , . . ., c5 } Ŵ ∪ {c2 , . . ., c5 } Ŵ ∪ {c1 , c3 , c4 , c5 } Ŵ ∪ {c1 , c4 , c5 } Ŵ ∪ {c1 } Ŵ ∪ {c1 , c5 } Ŵ ∪ {c1 , c4 }

{c1 , c2 , c3 } {c1 , c2 } {c1 } ∅ ∅ ∅ {c4 } ∅ ∅

{c4 , c5 } {c3 } {c2 } ∅ ∅ ∅ {c5 } ∅ ∅

{c1 , c4 , c5 } {c1 } {c1 } {c1 } ∅ ∅ {c4 , c5 } {c4 } {c5 }

FIGURE 7.2 Activation sequence of the different QUICKXPLAIN instances (for details see Table 7.2).

QUICKXPLAIN determines exactly one conflict set per computation. In order to identify all minimal conflicts in C, this algorithm has to be combined with a HSDAG-based diagnosis algorithm (see Section 7.4). How QUICKXPLAIN determines a minimal conflict can best be explained on the basis of our working example (see Table 7.2). The activation hierarchy for the recursive function QX is depicted in Figure 7.2. The function QX adds additional constraints (from C2 ) to the background knowledge as long as the resulting constraint set remains consistent. If it becomes inconsistent, the algorithm leaves out the remaining constraints. For example, in Table 7.2 (step 5) the set {c1 , c3 , c4 , c5 } is inconsistent and the remaining constraint c2 can be left out. On the other hand, if the background knowledge is consistent and only one constraint remains that induces the inconsistency, this constraint must be part of the conflict set. For example, in Table 7.2 (step 4) the background knowledge consists of the constraints {c2 , . . ., c5 } and c1 remains as single constraint. It is clear that c1 is part of the conflict since {c2 , . . ., c5 } is consistent but {c2 , . . ., c5 } ∪ {c1 } is inconsistent.

7.4 Determining Minimal Diagnoses

79

Table 7.3 Runtime evaluation: The average runtime in milliseconds (ms) needed by SIMPLECONFLICTDETECTION (SCD) and QUICKXPLAIN to calculate one minimal conflict set (on a standard PC). The basis for this evaluation are knowledge bases from www.splot-research.org. Domain

#con.

#var.

QUICKXPLAIN (ms)

SCD (ms)

DELL laptops Smarthomes Cars Xerox printers

285 73 150 242

47 55 73 158

75.7 42.6 42.9 78.1

643.2 89.6 406.2 812.2

Algorithm Analysis. When comparing the performance of SIMPLECONFLICTDETECTION with QUICKXPLAIN we can see that QUICKXPLAIN has the potential to reduce the number of needed consistency checks. In our working example, SIMPLECONFLICTDETECTION needs 11 consistency checks whereas Q  XPLAIN only needs eight consistency checks. In the worst case, the algorithm needs  UICK 2k × log2 nk + 2k where k is the set size of the minimal conflict and n is the number of constraints in C   (Junker, 2004). The best case complexity with regard to the number of consistency checks is log2 nk +2k. Note that both of the presented conflict detection algorithms determine conflicts depending on the constraint ordering. If we reverse the ordering of the constraints of both algorithms, we would receive the conflict set C S2 = {c1 , c2 , c5 } first. For a more detailed discussion of issues related to constraint orderings and their role in conflict detection refer to Junker (2004).

7.3.3 Runtime Performance of Conflict Detection Algorithms We conclude our discussion of conflict detection issues with an analysis of the runtime performance of the presented algorithms when executed on real-world configuration datasets taken from www.splotresearch.org. The average runtime of the two algorithms was measured in milliseconds (ms) where in each setting the ordering of the constraints was randomized and each setting was executed 100 times. It becomes clear that QUICKXPLAIN clearly outperforms SIMPLECONFLICTDETECTION in all of the analyzed settings (see Table 7.3). A major influence factor for the performance of QUICKXPLAIN is the size of conflict sets—the more elements in the conflicts, the more consistency checks are needed for determining one minimal conflict set. Another factor that has an impact on the performance of QUICKXPLAIN is ordering of the constraints in the consideration set C. The more these constraints are spread over C the more consistency checks can be expected since less constraints can be omitted in early phases of QX execution.

7.4 Determining Minimal Diagnoses Conflict sets help to identify areas of inconsistencies within a set of constraints. If we want to know the minimal set of constraints that have to be adapted (or deleted from the configuration knowledge base) such that a solution can be found for the given configuration task, we need to determine the (minimal) diagnoses with regard to the determined conflict sets. Based on our definition of a conflict set in Section 7.3, we now introduce the definition of a diagnosis task and the corresponding diagnosis (solution).

80

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

FIGURE 7.3 A diagnosis is a subset of C (AC = C ∪B) such that B∪C − is consistent. is minimal if no subset of fulfills the diagnosis property. B again represents the background knowledge. An example diagnosis is 1 = {c1 }.

Definition (Diagnosis Task). A diagnosis task can be defined by the tuple (C, AC) where AC = B ∪ C, B is the background knowledge, and C is the set of constraints to be analyzed. Before discussing potential algorithms that support the calculation of minimal diagnoses, we introduce the definition of a diagnosis that represents a solution to a given diagnosis task (C, AC). The basic idea of diagnosis determination is depicted in Figure 7.3. Definition (Diagnosis). A diagnosis for a given diagnosis task (C,AC) is a set of constraints ⊆ C such that B ∪ C − is consistent. A diagnosis is minimal if there does not exist a diagnosis ′ ⊂

with the diagnosis property. Finally, a minimal diagnosis is denoted as minimal cardinality diagnosis if there does not exist a minimal diagnosis ′ with | ′ | < | |. A widespread approach to the determination of diagnoses (hitting sets) is the construction of a HSDAG. The algorithm is known as hitting set directed acyclic graph algorithm, which has been introduced by Reiter (1987).

7.4.1 Hitting Set Directed Acyclic Graph (HSDAG) The HSDAG algorithm supports the determination of minimal diagnoses. Since the algorithm performs diagnosis search typically in breadth-first fashion, it supports the determination of minimal cardinality diagnoses (i.e., minimal diagnoses with the lowest possible number of included constraints). However, the algorithm is complete; after returning minimal cardinality diagnoses, it returns all other diagnoses contained in the consideration set C. HSDAG structures can be established by repeatedly activating a conflict detection algorithm (e.g., SIMPLECONFLICTDETECTION or QUICKXPLAIN) and to analyze the different possibilities to resolve the returned conflict. Since this is a simple implementation of a breadth-first search strategy, we do not provide an algorithm here. For example, in Figure 7.4 the first minimal conflict set returned by the conflict detection algorithm is C S1 : {c1 , c4 , c5 }. If we resolve the conflict C S1 , by deleting the constraint c4 , another conflict set will be identified – C S2 : {c1 , c2 , c5 }.

7.4 Determining Minimal Diagnoses

81

FIGURE 7.4 Breadth-first based search for diagnoses on the basis of the minimal conflict sets CS1 = {c1 , c4 , c5 } and CS2 = {c1 , c2 , c5 }. The resulting minimal diagnoses are 1 = {c1 }, 2 = {c5 }, and 3 = {c2 , c4 }.

FIGURE 7.5 Breadth-first based search for conflicts on the basis of the minimal diagnoses 1 = {c1 }, 2 = {c5 }, and

3 = {c2 , c4 }. The resulting minimal conflict sets are CS1 = {c1 , c2 , c5 }, CS2 = {c1 , c4 , c5 }.

Due to the minimality of C S1 we have exactly three different alternatives to resolve the conflict (by deleting one of its elements). The HSDAG algorithm is complete—all different alternatives to resolve the given conflicts are analyzed. For example, if we delete c1 from C S1 , we have already determined our first diagnosis, 1 = {c1 }. The second minimal cardinality diagnosis that can be derived from the HSDAG is 2 = {c5 }. There is a third minimal diagnosis (which is not a minimal cardinality one):

3 = {c2 , c4 }. The HSDAG algorithm (Reiter, 1987) not only supports the determination of hitting sets in terms of diagnoses—given a predefined set of diagnoses we are also able to derive all corresponding minimal conflicts (see, e.g., Figure 7.5). Typical HSDAG implementations are based on a number of additional concepts that help to improve the performance of diagnosis (conflict set) detection. First, conflicts (diagnoses) can be reused in the sense that already determined conflicts (diagnoses) can be reused for

82

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

those paths of the HSDAG which do not include the corresponding elements. In our working example (see Figure 7.5) there is no possibility to reuse a conflict set due to the fact that there is only one path to the leaf node of the HSDAG. A second possibility to improve the performance of diagnosis search is to close specific paths in the tree that have already been expanded in other parts of the tree. In our working example (see Figure 7.3), the path {c1 } directly leads to a diagnosis. For this reason it does not make sense to further expand other paths that include c1 . We can also take into account situations where two paths contain the same set of elements. In such a situation, one of these paths can be closed (i.e., does not have to be expanded further).

7.4.2 FastDiag There are many situations where not all the existing diagnoses are of relevance to the user. For example, when interacting with a configurator, the user is not interested in having to handle a possibly huge number of alternative diagnoses. There is a need for algorithms that are able to determine so-called leading diagnoses quickly, which can then be analyzed and evaluated by the user. Since in many cases not all possible diagnoses can be determined (for performance reasons), diagnoses assumed to be relevant for the user are determined first—these diagnoses are denoted as leading diagnoses. FASTDIAG is an algorithm that efficiently determines leading diagnoses without the additional overhead of determining conflict sets. It is easy to implement (no conflict detection and HSDAG algorithm are needed for determining one diagnosis) and is specifically useful in interactive configuration settings, for example, to support the user in situations where no solution can be found (Felfernig et al., 2012). In the line of QUICKXPLAIN, FASTDIAG heavily relies on the concept of divide and conquer. Assuming that the set AC is inconsistent, the major idea is to divide the set of constraints C into two different subsets C1 and C2 . If, for example, AC − C1 is consistent, we already know that the set C1 includes a diagnosis and, as a consequence, there is no need to further analyze C2 with regard to further diagnosis elements. A major advantage of FASTDIAG is that it is based on conflict-independent search strategies (i.e., no conflicts are needed for determining a diagnosis). FASTDIAG determines exactly one diagnosis at a time (if one exists). If we are interested in all diagnoses for a given set of constraints AC, we have to combine FASTDIAG with a corresponding HSDAG algorithm (see the example in Figure 7.5). How FASTDIAG determines minimal diagnoses can best be explained using our working example (see Table 7.4). The activation hierarchy for the FASTDIAG function is depicted in Figure 7.6. The algorithm checks whether the deletion of constraints (from AC) makes the remaining constraints consistent. For example, if we delete C2 from AC in step 1 (Table 7.4) we are able to restore the consistency. At the same time we also know that there must be a diagnosis in C2 since its deletion from AC contributed to the restoration of consistency. Furthermore, there is no need to search for a diagnosis in C1 . Algorithm Analysis. When comparing the performance of HSDAG with FASTDIAG we can see that FASTDIAG has the potential the reduce the number of needed consistency checks especially in scenarios where there is a need for identifying so-called leading diagnoses (i.e., not the complete set of diagnoses).   In the worst case, FASTDIAG needs 2d × log2 dn + 2d where d is the set size of the minimal diagnosis and n is the number of constraints in C (Junker, 2004). The best case complexity with regard to the number of consistency checks is log2 dn + 2d. The efficiency of FASTDIAG can best be documented by the fact that the number of consistency checks needed for determining one diagnosis is similar to the number of consistency checks needed by QUICKXPLAIN to determine exactly one conflict set. Typically, there is more than one conflict set in an

7.4 Determining Minimal Diagnoses

83

Table 7.4 Example of FASTDIAG: Ŵ = {cα , cβ , cγ , cδ , cǫ , cφ , cι } is the (original) background knowledge and = {c5 } is the returned diagnosis. The activation sequence of the different FASTDIAG instances is depicted in Figure 7.6. Step

D

C

AC

C1

C2

Return

1 2 3 4 5

∅ {c4 , c5 } ∅ {c5 } ∅

{c1 , . . ., c5 } {c1 , c2 , c3 } {c4 , c5 } {c4 } {c5 }

Ŵ ∪ {c1 , . . ., c5 } Ŵ ∪ {c1 , c2 , c3 } Ŵ ∪ {c1 , . . ., c5 } Ŵ ∪ {c1 , . . ., c4 } Ŵ ∪ {c1 , . . ., c5 }

{c1 , c2 , c3 } ∅ {c4 } ∅ ∅

{c4 , c5 } ∅ {c5 } ∅ ∅

c5 ∅ c5 ∅ c5

FIGURE 7.6 Activation sequence of the different FASTDIAG instances (for the details see Table 7.4).

inconsistent configuration knowledge base. Let n cs be the number of minimal conflict sets in a constraint set and n diag be the number of minimal diagnoses, then we need exactly n diag calls of the function F D (see Algorithm 7.3) plus n cs additional consistency checks and n cs activations of QUICKXPLAIN with n diag additional consistency checks for determining all diagnoses. The results of a performance evaluation (comparison of the HSDAG-based approach with FASTDIAG) are depicted in Table 7.5.

84

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

Table 7.5 Runtime evaluation: The average runtime in milliseconds (ms) needed by HSDAG and FASTDIAG to calculate one minimal diagnosis (on a standard PC). The basis for this evaluation are knowledge bases from www.splot-research.org (Dell laptops (laptops), smarthomes (homes), cars, and Xerox printers (printers)). Domain

#con.

#var.

#i Laptops Homes Cars Printers

285 73 150 242

47 55 73 158

FASTDIAG (ms)

HSDAG (ms)

1

5

10

1

5

10

1638.7 593.1 1404.4 2871.9

2792.3 2433.5 2730.8 6927.2

3464.1 3167.8 3606.0 12091.0

2668.9 2074.2 5741.1 >100k

4977.6 2151.4 6347.9 >100k

5336.3 2241.2 6942.0 >100k

7.4.3 Further Approaches We now sketch two further approaches than can be used for the determination of diagnoses. First, we show how to represent the task of identifying minimal cardinality diagnoses as an optimization problem. This approach is based on the assumption that all minimal conflicts have been determined before the start of the diagnosis process (see, e.g., Fijany and Vatan, 2004). Second, we show how to determine minimal cardinality diagnoses in the simple case that the complete set of possible configurations is available—in this case, all diagnoses are known beforehand and the task is to identify the minimal ones (see, e.g., Jannach, 2008; Schubert and Felfernig, 2011; Schubert et al., 2010). Diagnosis as Optimization Problem. We explain the approach to represent a diagnosis task as an optimization problem on the basis of the example depicted in Table 7.6. Each minimal conflict set C Si is represented by a tuple that describes for each constraint ci whether it is part of the conflict set or not (1 = ci is part of the conflict set, 0 = ci is not part of the conflict set). On the basis of this information we are able to define a corresponding optimization problem. Each constraint ci of Table 7.6 is represented by a corresponding variable xi with dom(xi )={0,1}. The conflict sets C Si are represented in the form of constaints csi , for example, cs1 : x1 + x4 + x5 ≥ 1 requires that at least one constraint out of {x1 , x4 , x5 } has to be deactivated; that is, xi = 1 denotes the fact that constraint ci is inactive (which also means that the corresponding conflict has been resolved). The complete set of constraints that corresponds to the conflict sets in Table 7.6 is the following. cs1 : x1 + x4 + x5 ≥ 1. cs2 : x1 + x2 ≥ 1. cs3 : x1 + x3 ≥ 1. cs4 : x2 + x3 ≥ 1. To complete the definition of the optimization problem, we introduce an optimization criterion. This criterion (see Formula 7.1) expresses the fact that the number of constraints that are part of at least one minimal conflict set and that are deactivated should be minimized. For further details on optimization-based diagnosis refer to Fijany and Vatan (2004). (7.1) minimize : x1 + x2 + x3 + x4 + x5 .

7.4 Determining Minimal Diagnoses

85

Table 7.6 Representation of a diagnosis task as optimization problem. In this case, all minimal conflict sets (CS1 , . . ., CS4 ) have to be determined before the optimization can start (1 (0) denotes the fact that ci is part (not part) of the minimal conflict set). Conflict Set

c1

c2

c3

c4

c5

CS1 CS2 CS3 CS4

1 1 1 0

0 1 0 1

0 0 1 1

1 0 0 0

1 0 0 0

Table 7.7 A simple configuration problem defined by the variables V = {v1 , v2 , v3 }, dom(vi ) = {1,2,3}, and the constraint cp = conf 1 ∨conf 2 ∨conf 3 ∨conf 4 ∈ CKB . Variables

conf 1

conf 2

conf 3

conf 4

v1 v2 v3

1 2 3

3 2 1

1 2 2

1 2 1

Table 7.8 Example user requirements CR and their relationship to the configurations conf 1 , . . ., conf 4 (1 = requirement supported, 0 = not supported). User Requirements

conf 1

conf 2

conf 3

conf 4

v1 = 1 v2 = 1 v3 = 1 support

1 0 0 1

0 0 1 1

1 0 0 1

1 0 1 2

Filtering Minimal Cardinality Diagnoses. We explain the approach to determine minimal cardinality diagnoses in the case that all possible configurations are already available (see Tables 7.7 and 7.8). Table 7.7 depicts the definition of a configuration task defined by a set of variables (V ), their domains (dom(vi )), and a constraint c p that describes the set of possible configurations (c p = con f 1 ∨con f 2 ∨con f 3 ∨con f 4 ). On the basis of the information contained in Table 7.7 we are able to derive an intermediate representation that indicates for each user (customer) requirement (∈ C R )6 and each configuration (con f i ) whether the requirement is supported by con f i or not (see Table 7.8). The support value indicates how 6 For

details on the definition of a configuration task see also Chapter 6.

86

CHAPTER 7 Conflict Detection and Diagnosis in Configuration

many of the user requirements are supported by the configuration; for example, configuration con f 1 supports the user requirement v1 = 1 but not the remaining ones; consequently the support of con f 1 = 1. It should be clear now that we are interested in diagnoses for the given set of requirements—the minimal (cardinality) set of requirements that have to be deleted such that a solution can be identified. On the basis of the intermediate representation (see Table 7.8) it is straightforward to determine, for example, one minimal cardinality diagnosis. The configuration con f i with the maximum support also defines a minimal cardinality diagnosis since there does not exist a diagnosis ′ with | ′ | < | | (if this would be the case then would not have the maximum support value). In our working example, the only minimal cardinality diagnosis is = {v2 = 1}.

7.5 Conclusion In this chapter, we sketched major concepts, techniques, and algorithms that support anomaly management in constraint-based application development, especially configurator application development. These concepts are the basis for other chapters in this book (see Friedrich et al., 20147 and Felfernig et al., 20148 ).

Acknowledgments The work presented in this chapter was funded by the Austrian research promotion agency (grant number: 827587).

References Barker, V., O’Connor, D., Bachant, J., Soloway, E., 1989. Expert systems for configuration at Digital: XCON and beyond. Communications of the ACM 32 (3), 298–318. Chandola, V., Banerjee, A., Kumar, V., 2009. Anomaly Detection: A Survey. ACM Computing Surveys 41 (3), 1–58. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., 2004. Consistency-based diagnosis of configuration knowledge bases. Artificial Intelligence 152 (2), 213–234. Felfernig, A., Zehentner, C., Blazek, P., 2011. CoreDiag: eliminating redundancy in constraint sets. In: 22nd International Workshop on Principles of Diagnosis (DX’2011), Murnau, Germany, pp. 219–224. Felfernig, A., Schubert, M., Zehentner, C., 2012. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 26 (1), 53–62. Felfernig, A., Schippel, S., Leitner, G., Reinfrank, F., Isak, K., Mandl, M., Blazek, P., Ninaus, G., 2013. Automated repair of scoring rules in constraint-based recommender systems. AI Communications 26 (2), 15–27. Felfernig, A., Reinfrank, F., Ninaus, G., Blazek, P., 2014. Redundancy detection in configuration knowledge. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 157–166 (Chapter 12). Fijany, A., Vatan, F., 2004. New approaches for efficient solution of hitting set problem. In: Winter International Symposium on Information and Communication Technologies. Trinity College Dublin, Cancun, Mexico, pp. 1–6. 7 Chapter 8 Chapter

11. 12.

References

87

Fleischanderl, G., Friedrich, G.E., Haselböck, A., Schreiner, H., Stumptner, M., 1998. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems 13 (4), 59–68. Friedrich, G., Jannach, D., Stumptner, M., Zanker, M., 2014. Knowledge engineering for configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 139–155 (Chapter 11). Hotz, L., Felfernig, A., Stumptner, M., Ryabokon, A., Bagley, C., Wolter, K., 2014. Configuration knowledge representation and reasoning. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 41–72 (Chapter 6). Jannach, D., 2008. Finding preferred query relaxations in content-based recommenders. In: Chountas, P., Petrounias, I., Kacprzyk, J. (Eds.), Intelligent Techniques and Tools for Novel System Architectures, London, UK, Studies in Computational Intelligence, vol. 109, pp. 81–97. Junker, U., 2004. QUICKXPLAIN: preferred explanations and relaxations for over-constrained problems. In: McGuinness, D.L., Ferguson, G. (Eds.), 19th International Conference on Artifical Intelligence (AAAI’04). AAAI Press, San Jose, CA, pp. 167–172. Reiter, R., 1987. A theory of diagnosis from first principles. Artificial Intelligence 32 (1), 57–95. Schubert, M., Felfernig, A., 2011. BFX: diagnosing conflicting requirements in constraint-based recommendation. International Journal on Artificial Intelligence Tools 20 (2), 297–312. Schubert, M., Felfernig, A., Mandl, M., 2010. FastXPlain: conflict detection for constraint-based recommendation problems. In: García-Pedrajas, N., Herrera, F., Fyfe, C., Benítez, J., Ali, M. (Eds.), Trends in Applied Intelligent Systems (Proceedings of 23rd International Conference on Industrial Engineering and Other Applications of Applied Intelligent Systems, IEA/AIE 2010). Lecture Notes in Computer Science, vol. 6096. Springer, Cordoba, Spain, pp. 621–630.

This page is intentionally left blank

CHAPTER

User Interfaces for Configuration Environments

8

Gerhard Leitner* , Alexander Felfernig† , Paul Blazek‡ , Florian Reinfrank† and Gerald Ninaus† * Alpen-Adria

Universität Klagenfurt, Klagenfurt, Austria University of Technology, Graz, Austria ‡ cyLEDGE, Vienna, Austria

† Graz

Abstract: Configuration technologies are successfully applied in different domains such as telecommunication, financial services, and automotive. User interfaces of configuration environments play a key role with regard to two major aspects. First, users of a configurator application need interfaces that allow for efficient and intuitive configuration processes. Second, knowledge engineers and domain experts (developers of configurator applications) need interfaces that provide intelligent support of development and maintenance operations. In this chapter we discuss aspects that should be taken into account when developing user interfaces for configurator end users and application developers.

8.1 Introduction Configuration is one of the key technologies of mass customization (Anderson and Pine, 1996; Pine, 1999; see also Piller and Blazek, 20141 ). It can be defined as a special case of design activity where the resulting artifact is composed from a predefined set of component types and is consistent with a given set of constraints (Sabin and Weigel, 1998). Configuration environments allow endusers to design their own individualized products and services and knowledge engineers and domain experts to develop configurator applications (mainly user interfaces and knowledge bases). For both types of users, the user interface of the configuration environment plays a key role. First, a major precondition for lasting acceptance and application is that end users can easily configure a product that fits their wishes and needs (Ardissono et al., 2003; Falkner et al., 2011). Second, knowledge engineers and domain experts need technologies that allow effective development and maintenance, which are a precondition for upto-date knowledge bases (Blythe et al., 2001). For both scenarios we discuss properties of user interfaces that help to make the application of configuration technologies a success.2 The major contributions of this chapter are the following. We provide an overview of important criteria to be taken into account when developing user interfaces for configurator applications as well as user interfaces for the corresponding knowledge engineering environments (see Section 8.2). For the criteria, we present and exemplify supporting technologies (see Section 8.3). In the following, we 1 Chapter 2 An

9. overview of configuration tools and user interfaces can be found in Part V.

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00008-6 © 2014 Elsevier Inc. All rights reserved.

89

90

CHAPTER 8 User Interfaces for Configuration Environments

discuss usability issues related to configurator user interface construction in industrial practice (see Section 8.4). Section 8.5 concludes this chapter.

8.2 Design Principles for Configurator User Interfaces Contrary to conventional product design where experienced product designers and managers are responsible for the design of product alternatives offered to a customer, the task of customization is now also presented to end users. An important aspect in this context is that we cannot expect end users to possess detailed technical product domain knowledge. Moreover, end users typically do not know their preferences and needs beforehand, which makes the configuration task even more challenging (Simonson, 2003). As analyzed by Randall et al. (2005), there are problems with existing configurator user interfaces that have to be tackled in order to increase the usability of configuration technologies. We now summarize five key principles to be taken into account when developing user interfaces for configuration environments (see Randall et al., 2005). In this context we focus on both interfaces for users of a configurator application as well as interfaces that support knowledge engineers and domain experts in configurator application development and maintenance. A discussion of relevant approaches to support the presented design principles is given in Section 8.3. Principle 1: Customize the Customization Process. Sales persons are typically adapting their customer interaction style depending on the type of customer. For example, customers interested in technical details should be supported by in-depth technical information and corresponding analyses. In contrast, customers without expertise in the product domain should be supported by a more function-oriented dialog where technical details are omitted. Since we can expect different types of end users of a configurator application, we need technical approaches that help to personalize the interaction with the configuration environment depending on the basic characteristics of the current user (see also Tiihonen et al., 20143 ). As proposed by Randall et al. (2005), a configuration environment should support at least two different types of user interfaces: a needs-based interface for non-experts and a parameter-based one for users who want to perform configuration primarily on the basis of the given set of technical product properties. Similar to end users there are also different types of knowledge engineers and domain experts responsible for the development and maintenance of a configurator application. There may be experts who know every technical property of the product, as well as novices or new employees who recently started and did not acquire enough expertise yet about the knowledge representation. These two types of users need different navigation styles. Principle 2: Provide Starting Points. Users of a configurator application can not only be differentiated with regard to their product preferences, they can also be differentiated with regard to their preferred product properties (i.e., properties of a product they are interested in and would like to specify). For example, one user of a car configurator prefers to start with a specification of the car type (e.g., limousine vs. combi) whereas another user prefers to specify the price as a parameter with the highest priority. In this context, a requirement for configurator user interfaces is the provision of so-called starting points, which can be seen as a kind of initial design from which the customer can continue the configuration activities. 3 Chapter

13.

8.2 Design Principles for Configurator User Interfaces

91

The important idea behind starting points is that not every user is interested in designing (configuring) a product from scratch but rather relies on existing basic settings (also known as stereotype configurations). Starting points should also be provided for knowledge engineers and domain experts. A knowledge engineer (or domain expert) with nearly no knowledge about an already existing configuration knowledge base clearly needs an indicator of where to best start the analysis of the knowledge base. Such starting points can improve the overall efficiency of developing a basic understanding of a knowledge base, or more generally, a configurator application. Another example of a starting point in the context of knowledge base development and maintenance are recommendations (see also Tiihonen et al., 2014)4 to inspect those parts of a knowledge base that have low understandability (Felfernig et al., 2013a). Principle 3: Support Incremental Refinement. Users of a configurator application typically construct their preferences within the scope of a configuration session (Simonson, 2003); that is preferences are not known beforehand. A requirement for user interfaces in this context is that the configurator should actively support sensitivity analysis in the sense that tradeoffs between different properties are visualized and alternatives to the current configuration are shown in an intuitive fashion. An easy way to support such a tradeoff analysis is to include product comparison functionalities—a comparison between different alternative configurations. An important functionality in this context is that the configurator is able to automatically determine alternative configurations on the basis of defined user preferences. Similarly, there is a need for the support of tradeoff analysis in the context of knowledge base development and maintenance. In this context, a knowledge engineer (or domain expert) should be supported in correction and extension activities. For example, if a domain expert has specified examples for the intended behavior of a configurator in terms of which configuration should be shown in which context (kind of test cases; see Friedrich et al., 20145 ) and the configurator is not able to fulfill these requirements, then the configurator should provide the means for explaining the given inconsistency (see Felfernig et al., 20146 and Friedrich et al., 2014). In this context, the user interface should support the comparison of explanations for the inconsistencies (e.g., diagnoses and repair proposals for faulty knowledge bases) and it should provide information about the pragmatics of changes to the knowledge base, for example, in terms of test cases, which are additionally accepted by the knowledge base due to the performed repairs. Principle 4: Exploit Prototypes to Avoid Surprises. A major obstacle for the willingness to purchase a product is the lack of trust in a given configuration (Felfernig et al., 2006b; Grabner-Kräuter and Kaluscha, 2003). Since configurations in many cases are unique, the exploitation of product evaluations for decision making is often impossible. Consequently, alternative concepts have to be provided, which help the customer to anticipate the post-purchase experience (Randall et al., 2005). In this context it is important to visualize the impact of different decision alternatives on the final configuration outcome. For example, a change of the interior color of a car has to be immediately shown to the user by directly visualizing the new interior of the selected car type. Another example is the configuration of financial service portfolios: after increasing the level of willingness to take risks or after increasing the expected yearly return rate of a financial service, the configurator should immediately show the possible consequences of the decision. For example, in terms of less available money due to plunging stock prices or, on a more visual level, in terms of the possibility of not being able to buy the envisioned car. 4 Chapter

13. 11. 6 Chapter 7. 5 Chapter

92

CHAPTER 8 User Interfaces for Configuration Environments

In the context of configurator application development, we need prototypes for visualizing the consequence of decisions made during the configuration process. For example, when developing a knowledge base, knowledge engineers and domain experts should be able to test the new version of the knowledge base by interacting with the configurator; new versions of a knowledge base have to be automatically integrated with the corresponding user interface. Another example of a visualization in the context of knowledge base development and maintenance is to show information regarding quality properties of the knowledge base (Felfernig et al., 2013a). If a knowledge engineer adapts or extends the knowledge base, feedback should be given immediately, for example, in terms of an indication of a deterioration or improvement of the level of maintainability (Felfernig et al., 2013a). Test cases often have to be adapted due to the fact that they fail after the completion of change operations. Such adaptations should be proactively supported by the configuration environment. Principle 5: Teach the Consumer. Often consumers do not have the technical background knowledge about important technical properties of the product. For example, customers do not usually know the performance specifications required for a specific processor type (Randall et al., 2005). Increasing knowledge about the properties of a configuration can also increase the corresponding willingness to buy (Felfernig et al., 2006a). As a consequence, we need mechanisms that assist users and help them to increase their personal product domain knowledge. Besides basic concepts such as help buttons, which explain the role of specific product parameters, more sophisticated explanation functionalities can be integrated into configuration environments. First, users typically need explanations as to why a concrete configuration has been recommended. This functionality can simply be supported by interpreting the information received from the configuration environment (i.e., which constraints were responsible for the calculation of the configuration). Second, users also need explanations in situations where no solution can be found by the configuration system. In this context, the user needs information regarding which requirements are responsible for the conflict as well as knowing what possible actions can be taken to arrive at a solution (see also Felfernig et al., 2014)7 . In the context of configuration knowledge acquisition and maintenance, similar explanation functionalities are needed: knowledge engineers and domain experts need to be informed about the sources of inconsistencies in the knowledge base (in case some of the test cases fail) and what the corresponding alternatives for repairing the knowledge base are. Another type of explanation stems from collaborative recommendation (Konstan et al., 1997) where explanations are typically presented in the form of users who purchased item A also purchased item B. This type of explanation can also be applied in the context of knowledge base development and maintenance, for example, in the form of users who changed constraint A also changed constraint B.

8.3 Technological Issues On the basis of our discussion of basic design principles for configurator user interfaces in the previous section, we now focus on a discussion of basic technologies that can help to support these design principles for end user interfaces and user interfaces for knowledge engineers. 7 Chapter

7.

8.3 Technological Issues

93

Customize the Customization Process. User interfaces of configurator applications can simply be implemented on the basis of explicit definitions of a configuration process. Such a process defines in which order parameters have to be specified by the user. For our computer configuration example (see Hotz et al., 20148 ) we can specify, for example, two different types of user interfaces. For experts in the domain of personal computers, we could provide a search interface where a user (customer) can specify the requirements at the level of technical product properties such as type of cpu, motherboard, operating system, screen, hd unit, internet, and application software. For non-experts in the product domain, a user interface could ask questions at a more abstract (needs-oriented9 ) level such as primary types of use (e.g., multimedia and game playing, programming, video editing, complex mathematical calculations, and office applications). This needs-oriented view on the product assortment is known as the functional architecture of a configurable product (see Hotz and Wolter, 201410 ). From the specification of preferences, the configurator application can then determine the corresponding technical properties. For example, video editing and complex mathematical applications require a multicore cpu architecture. At both levels (functional architectures and detailed technical product properties), questions asked to the customer have to be ranked. The simplest way to achieve this is to specify a static ordering where, for example, the question regarding type of cpu is asked first. However, more flexible approaches have been developed, which help to adapt their strategy regarding the selection of the next question depending on the navigation behavior of the user. One approach to support a selection of questions “on the fly” is to apply the concepts of collaborative filtering (Falkner et al., 2011; Konstan et al., 1997). The idea of collaborative filtering is to determine recommendations for the current user on the basis of the preferences of users with a similar navigation behavior as the current user. In our scenario, in order to determine the next question to ask the current user, we would determine users with a similar navigation behavior (the nearest neighbors) and on the basis of the preferences of the nearest neighbors try to select (recommend) the next question to ask the current user. A working example of such a collaborative dialog management is shown in Table 8.1. Users 1 through 5 have already completed their configuration sessions; for example, user 1 has first specified a value for CPU, then a value for OS, then an assignment of HD, motherboard, Screen, Internet, and finally Applications. The current user has already specified values for the parameters CPU and OS and we would like to predict which of the remaining parameters will next be specified by the current user. The nearest neighbors of the current user are user1, user3, and user4 since all of them have first selected a CPU, followed by an assignment of OS. Since the majority of nearest neighbors has selected motherboard as the third parameter, we recommend motherboard as the next parameter to be specified by the current user. For a more detailed overview of parameter selection methods refer to Falkner et al. (2011). A similar approach can support the navigation of knowledge engineers (domain experts) in complex knowledge bases (see the example in Table 8.2). In our scenario, the knowledge engineers (users 1–4) have already interacted with the knowledge base; for example, user 1 took a look at all the constraints in the following order: c5 , c2 , c3 , c1 , c4 , c6 .11 The current user has already inspected the constraints c5 8 Chapter

6.

9 Needs-oriented

view is a synonym for feature view and functional requirements (see, e.g., Mittal and Frayman, 1989). 10. 11 Note that for simplicity we assume that each stakeholder has inspected each constraint at least once. However, collaborative filtering algorithms also work in the case that the matrix is sparse.

10 Chapter

94

CHAPTER 8 User Interfaces for Configuration Environments

Table 8.1 Example of determining relevant questions on the basis of collaborative filtering (Konstan et al., 1997). User

CPU

MB

OS

Screen

HD

Internet

Applications

1 2 3 4 5 Current

1 3 1 1 2 1

4 1 3 3 1 ?

2 2 2 2 3 2

5 4 5 4 5 ?

3 5 4 5 4 ?

6 7 7 6 6 ?

7 6 6 7 7 ?

Table 8.2 Example of determining relevant constraints on the basis of collaborative filtering (Konstan et al., 1997). User

c1

c2

c3

c4

c5

c6

1 2 3 4 Current

4 3 1 3 ?

2 2 3 2 2

3 5 2 4 ?

5 6 4 5 ?

1 1 6 1 1

6 4 5 6 ?

and c2 . The constraint that should be recommended next to the current user is c1 since this one has been inspected next by the majority of the nearest neighbors of the current user (user 2 and user 4). The ICONE12 knowledge acquisition prototype is an example of a graphical knowledge acquisition user interface that includes recommendation technologies for proactively supporting knowledge engineers and domain experts in their development and maintenance activities. The ICONE user interface is depicted in Figure 8.1. On the left-hand side, the user can exploit typical functionalities such as product data (component) management, definition and maintenance of constraints, and the definition of the configuration process (dialog management). In addition to these basic functionalities, the ICONE environment includes intelligent recommendation functionalities that proactively support the user in inspecting the knowledge base (e.g., the functionality take a look at ... on the right-hand side of Figure 8.1). From the definition of products (components) and constraints, the ICONE knowledge acquisition user interface can directly generate the corresponding configurator applications for different platforms (iOS, Android, and HTML). Note that the exploitation of recommender algorithms and machine learning approaches in knowledge acquisition and maintenance scenarios is a young and evolving discipline; 12 ICONE

is the acronym for Intelligent Assistance for Configuration Knowledge Base Development & Maintenance (see www.ist.tugraz.at).

8.3 Technological Issues

95

FIGURE 8.1 ICONE Knowledge Acquisition Environment: Example of a simple requires relationship (see also Hotz et al., 2014).

significant improvements regarding the efficiency of configurator development processes can be expected in the future (Burke et al., 2011). Provide Starting Points. The basic approach to the provision of starting points is to predetermine parameter settings that are of interest for the user. Such starting points serve as default values, which are proposed to the user within the scope of a configuration session. On the one hand defaults can represent specific parameter settings, for example, in German-speaking countries the value for the keyboard part of the configuration is set to German. On the other hand, defaults can represent whole subconfigurations; for example, the default installation settings for a software package included in a computer configuration. Independent of the generic type of default (i.e., specific parameter setting vs. whole subconfiguration), defaults can be distinguished in terms of the way that default values are determined. Three basic types of defaults will be discussed in the following. Static Defaults. A parameter has a fixed predefined default value that is independent of the current configuration context. For example, the default value of the parameter internet is set to yes since it is assumed that most of the users want to have included the corresponding network hardware. The application of this type of default is limited since in many cases defaults depend on the context of user interaction. This aspect of contextualization is taken into account by the following two types of defaults. Rule-Based Defaults. Here the determination of defaults is personalized and the selection of default values is performed on the basis of predefined default rules. An example of such a rule is the following: if the user has selected “programming” as a main field of application then the default value of the parameter “memory” is set to xGB. Although this default type takes into account context information (on the basis of rules), rules trigger knowledge acquisition and maintenance efforts. The following default type does not rely on an explicit specification of contexts but on context learning on the basis of an analysis of already completed configuration sessions.

96

CHAPTER 8 User Interfaces for Configuration Environments

Table 8.3 Example of determining default values for the parameters of the computer configurator on the basis of collaborative filtering (Konstan et al., 1997). User

CPU

Motherboard

OS

Screen

HD

Internet

1 2 3 4 5 Current

CPUD CPUS CPUS CPUS CPUD CPUD

MBDiamond MBSilver MBSilver MBSilver MBDiamond MBDiamond

OSAlpha OSBeta OSBeta OSBeta OSAlpha ?

ScreenA ScreenB ScreenA ScreenB ScreenA ?

MedStore MedStore MaxStore MedStore MedStore ?

Yes No Yes No No ?

Adaptive Defaults. If we want to keep knowledge base development and maintenance efforts as low as possible, we have to develop mechanisms that are able to automatically determine parameter settings of relevance for the current user. Different types of machine learning approaches can be applied to support such an adaptive determination of defaults (Ardissono et al., 2003; Cöster et al., 2002; Falkner et al., 2011; Tiihonen and Felfernig, 2010). An example of the application of collaborative filtering is given in Table 8.3. The default value for the parameter OS (the operating system) proposed to the current user would be OS-Alpha since the nearest neighbors of the current user (the users 1 and 5) have choosen OS-Alpha. An example user interface that is based on adaptive default values is depicted in Figure 8.2. This configurator (RecoMobile) supports the configuration of mobile phones (for details see Tiihonen et al., 201413 ). In the context of knowledge engineering and maintenance scenarios, defaults play a major role as well. The recommendation of constraints (see Figure 8.1) that could be of relevance for the current user (knowledge engineer or domain expert) can be interpreted as a specific type of adaptive default. Similar defaults can be determined for diagnoses (Felfernig and Schubert, 2010) or sets of redundant constraints (i.e., constraints that do not change the semantics of the knowledge base when deleted; Felfernig et al., 2011). In this context, a default can be interpreted as a set of faulty or redundant constraints. Support Incremental Refinement. An important feature to support a user in preference construction is to explicitly visualize the existing tradeoffs between different configuration alternatives in corresponding comparison tables (Felfernig et al., 2006a). An approach often used to support such a tradeoff analysis is to simply rank alternative configurations with regard to their price (see Figure 8.3). Presenting configuration alternatives in such a way biases the product comparison toward an evaluation of the price attribute (see also Mandl et al., 201414 ). Since price is in many cases the most important decision criterion, such interfaces are often used in commercial settings. The major drawback of this type of product comparison is that the interface does not take into account the real preferences of the user. If user preference information is available, it can be taken into account when presenting configuration alternatives. For the purpose of our example let us assume that the preferences of the current user regarding the importance of the different product properties is known (see Table 8.4). Such preferences 13 Chapter 14 Chapter

13. 14.

8.3 Technological Issues

97

FIGURE 8.2 RECOMOBILE user interface for the representation of (adaptive) defaults.

Table 8.4 Example list of user preferences. Price

CPU

MB

Internet

5%

35%

35%

25%

can be obtained, for example, by directly asking the user or by learning from the interactions of previous users. Additionally, we have a utility evaluation of the different product properties (see Table 8.5).

98

CHAPTER 8 User Interfaces for Configuration Environments

FIGURE 8.3 Configuration comparison interface based on price ranking.

Table 8.5 Example list of product utilities. Attribute

Value

Utility

$ 389

$ 455

$ 612

CPU

CPUS CPUD MB-Diamond MB-Silver Yes No 0–400 401–600 601–1000

4 7 8 2 10 1 10 7 3

4∗ 0.35 = 1.4

4∗ 0.35 = 1.4

–

– –

– –

7∗ 0.35 = 2.45 8∗ 0.35 = 2.8

2∗ 0.35 = 0.7 –

2∗ 0.35 = 0.7 10∗ 0.25 = 2.5

10∗ 0.25 = 2.5

1∗ 0.25 = 0.25 10∗ 0.25 = 2.5

– –

– – 4.85

7∗ 0.25 = 1.75

MB Internet Price

Total

– 6.35

– – – –

3∗ 0.25 = 0.75 8.5

On the basis of this information and a corresponding utility function we can determine the userspecific utility of each configuration alternative x (Felfernig et al., 2013b; Winterfeldt and Edwards, 1986). The utility function used for the purposes of our example is shown in Formula 8.1 where x denotes a specific configuration alternative, importance(i) denotes the importance of product property i for the current customer, and contribution(x, i) denotes the utility of configuration x with regard to property i. utility(x) =

n 

importance(i) × contribution(x, i)

(8.1)

i

When combining the customer-specific preferences (Table 8.4) with the attribute utilities defined in Table 8.5, we receive the ranking configuration($ 612) > configuration($ 455) > configuration($ 389) (see Table 8.5). This shows that the most expensive configuration can also have the highest utility for a user. A corresponding comparison interface is sketched in Figure 8.4. Note that tradeoff analysis does not only play a role in the context of comparing different solution alternatives with regard to their utility for the user. In situations where no solution can be found for the current set of user requirements (specified preferences), the configurator application proposes a set of

8.3 Technological Issues

99

FIGURE 8.4 Configuration comparison interface based on utility-based ranking.

FIGURE 8.5 Repair comparison interface based on utility-based ranking.

repair alternatives—alternatives for changes to the current set of requirements that can guarantee the retrieval of a solution (Felfernig et al., 2009, 2013c). Such repair alternatives can be represented in the same way as alternative configurations (see Figure 8.5). Tradeoff analysis in the context of configuration knowledge base development and maintenance has a similar need in terms of user support. When testing a knowledge base, knowledge engineers have to figure out which constraints are responsible for the faulty behavior of a knowledge base (e.g., the knowledge base calculates configurations that are not feasible on the technical level) and that are the repair alternatives to be taken into account. In this situation, different subsets of constraints have to be evaluated with regard to the probability of being responsible for the faulty behavior of the knowledge base. A detailed technical discussion of the techniques supporting the automated identification of faulty constraint sets can be found in Friedrich et al. (2014).15 Exploit Prototypes to Avoid Surprises. An important commercial aspect to consider is the concept of trust that sides the act of purchasing. This is even more important with online configuration environments (see Felfernig et al., 2007, 2006a, 2008; Grabner-Kräuter and Kaluscha, 2003). Due to large solution spaces of configurable offerings, individual configurations are in many cases unique. As a consequence, product evaluations are not available. A concrete visualization of the outlook (and pragmatic) of the 15 Chapter

11.

100

CHAPTER 8 User Interfaces for Configuration Environments

FIGURE 8.6 COMBEENATION: Integrated development and visualization.

configuration is crucial in order to give the customer a clear impression of the product he/she will purchase. Examples of such visualization-based configurator user interfaces are shown in Part IV. Prototyping concepts also play a major role in the context of configurator application development and maintenance. When creating or adapting a configurator application, the knowledge engineer should be able to immediately analyze the impact of changes on the layout of the configurator interface as well as on the underlying configuration logic. The configuration environment Combeenation16 is an innovative look and feel environment that supports application development on a graphical level (see Figure 8.6). The definition of a configuration knowledge base is product-centered, which means that component and constraint definitions are directly attached to a graphical representation of the configurable product. This approach allows for rapid prototyping processes in the context of knowledge-based systems development and maintenance. Furthermore, Combeenation allows for immediate user testing and 16 See

www.combeenation.com.

8.3 Technological Issues

101

FIGURE 8.7 WECOTIN: Configuration environment (car configurator).

feedback; erroneous behavior of the application can be immediately reported to the responsible knowledge engineer. Further research related to graphical development, testing, and debugging environments for configurator applications can be found in Felfernig (2007). Teach the Consumer. The basic and widespread approach to support a better understanding of configuration results as well as situations where inconsistencies occur is to provide explanations (Sinz et al., 2007). Basically, we can differentiate between two basic forms of explanations. First, an explanation can provide a set of argumentations as to why a configuration alternative has been recommended (Felfernig et al., 2006a). Second, in situations where the configurator cannot find any solution, the user has to be informed about the underlying inconsistencies and potential repairs. An example of the visualization of such inconsistencies is provided in Figure 8.7, which shows the screenshot of the WeCoTin configuration environment (Tiihonen et al., 2013). This environment represents the result of pioneer research in the field of answer set programming (ASP; see also Hotz et al., 201417 and Tiihonen and Anderson, 2014).18 In the context of knowledge base development and maintenance, knowledge engineers and domain experts are in a similar situation—they have to be informed about the sources of faulty behavior; for example, in the case that certain test cases become invalid due to a prior change to the knowledge base. 17 Chapter

18 Chapter

6. 26.

102

CHAPTER 8 User Interfaces for Configuration Environments

Table 8.6 Design principles of configurator user interfaces and technological foundations. Principle

Technological Foundations

Customize the Customization Process Provide Starting Points

Parameter Selection (Falkner et al., 2011) Adaptive Knowledge Acquisition (Burke et al., 2011) Recommendation of Defaults (Falkner et al., 2011; Tiihonen and Felfernig, 2010) Recommendation of Knowledge Base Diagnoses (Felfernig et al., 2012) Configuration Comparison (Felfernig et al., 2006a; Heiskala et al., 2003) Diagnosis Comparison (Felfernig et al., 2009) Configuration Visualization (Fano and Kurth, 2003) Graphical Testing and Debugging (Felfernig, 2007) Personalized Diagnoses (Felfernig et al., 2009) Explanations (Friedrich et al., 2011)

Support Incremental Refinement Exploit Prototypes to Avoid Surprises Teach the Consumer

In such situations, diagnoses take over the role of explanations (see also Felfernig et al., 201419 ). Beside these basic types of explanations, all the criteria for the development of configurator user interfaces discussed in the prior sections also contribute to a better understanding of the product domain and the underlying configuration knowledge bases. Customizing the customization process allows users to deal with topics they are interested in and as a consequence, to know more about relevant concepts of the product domain. Similarly, knowledge engineers can efficiently develop a basic understanding of the most relevant components and constraints part of the configuration knowledge base. The provision of starting points offers initial and reasonable settings in terms of, for example, a partial configuration and thus helps to reduce overheads related to the design of consistent configurations. Furthermore, starting points make knowledge engineering operations more efficient due to the availability of additional indicators of potential sources of inconsistencies. Knowledge engineers and domain experts are supported in developing a basic understanding of the tradeoffs with regard to alternative repair operations needed to restore the consistency of a knowledge base. Supporting the concept of incremental refinement, for example, on the basis of product comparison pages, helps the user to develop a clear understanding of existing tradeoffs in the space of solutions offered by the configuration knowledge base. Finally, prototypes that are visualizing alternative configurations can significantly help to develop a better understanding and clearer preferences regarding certain solution alternatives. In the context of knowledge base development, such visualizations help to understand alternative impacts of change operations on the next version of the knowledge base (Felfernig, 2007). To summarize the discussed design principles for user interfaces of configuration environments, we provide an overview of these principles, including related technological foundations (see Table 8.6). 19 Chapter

7.

8.5 Conclusion

103

8.4 Usability Issues in Configurator User Interface Development The diversity of the configuration model has a strong influence on the design and structure of user interfaces—nevertheless certain commonalities can be identified. The Configurator Database Project20 provides a collection of online configurators and includes more than 800 entries. After analyzing configuration environments contained in this database, we detected that more than 50% of the analyzed configurators show the following basic characteristics: • • • • •

Selected components are summarized at the end of the configuration process. Products available for configuration are presented as images. Process navigation, if available, is structured on a horizontal plane. Choice fields are positioned next to and/or beneath the product picture. Shopping cart, order button, and total price are clearly visible.

A configurator application that takes into account the mentioned characteristics is depicted in Figure 8.8. It is intended as an example for developers of configurator applications. Important hints regarding the design of individual configurator user interface elements are the following: • • • • • • •

The logo should be shown in a dominant position for a fast identification. The navigation bar should be clearly visible and shown unfragmented. The size of product (configuration) images should be sufficient to see details. Selection box(es) should follow a logical clustering. Prices (price tables) should be accessible in all steps of a session. User preferences should be adaptable (e.g., by back/forward navigation). Shopping cart and order-button should be available for completion purposes.

Summarizing, a close-to-reality approach is recommended to reduce the uncertainties that a customer feels regarding a product that is not tangible yet. For a more detailed discussion on usability issues in configurator user interface development refer to Rogoll and Piller (2004).

8.5 Conclusion With this chapter we provide an overview of relevant principles of developing user interfaces for configuration environments. In this context we focused on both types of user interfaces, interfaces for the end-user and interfaces for knowledge engineers and domain experts who are in charge of knowledge base development and maintenance. In addition to this discussion of design principles, we proposed a couple of technologies that help to achieve these principles.

20 See

www.configurator-database.com.

104

CHAPTER 8 User Interfaces for Configuration Environments

FIGURE 8.8 A prototype web-based bicycle configurator (see www.cyledge.com).

Acknowledgments The work presented in this chapter was partially funded by the Austrian research promotion agency (grant number: 827587).

References Anderson, D., Pine, J.B., 1996. Agile Product Development for Mass Customization. McGraw-Hill. Ardissono, L., Felfernig, A., Friedrich, G., Goy, A., Jannach, D., Petrone, G., Schäfer, R., Zanker, M., 2003. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine 24 (3), 93–108. Blythe, J., Kim, J., Ramachandran, S., Gil, Y., 2001. An integrated environment for knowledge acquisition. In: 6th International Conference on Intelligent User interfaces. ACM, New York, Santa Fe, NM, pp. 13–20. Burke, R., Felfernig, A., Göker, M., 2011. Recommender systems: an overview. AI Magazine 32 (3), 13–18.

References

105

Cöster, C., Gustavsson, A., Olsson, R., Rudström, A., 2002. Enhancing web-based configuration with recommendations and cluster-based help. In: Francesco, R., Barry, S. (Eds.), AH’02 Workshop on Recommendation and Personalized in e-Commerce. Universidad de Málaga, Málaga, Spain, pp. 30–40. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Fano, A., Kurth, S., 2003. Personal Choice Point: helping users visualize what it means to buy a BMW. In: International Conference on Intelligent User Interfaces IUI’03. ACM, New York; Miami, FL, pp. 46–52. Felfernig, A., 2007. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management 54 (1), 41–56. Felfernig, A., Schubert, M., 2010. Diagnosing inconsistent requirements. In: Hotz, L., Haselböck, A. (Eds.), 19th European Conference on Artificial Intelligence (ECAI-2010), Workshop on Configuration. Lisbon, Portugal, pp. 15–20. Felfernig, A., Friedrich, G., Jannach, D., Zanker, M., 2006a. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC) 11 (2), 11–34. Felfernig, A., Teppan, E., Gula, B., 2006b. Knowledge-based recommender technologies for marketing and sales. International Journal of Pattern Recognition and Artificial Intelligence (IJPRAI) 21 (2), 333–354 (special issue of Personalization Techniques for Recommender Systems and Intelligent User Interfaces). Felfernig, A., Friedrich, G., Gula, B., Hitz, M., Kruggel, T., Melcher, R., Riepan, D., Strauss, S., Teppan, E., Vitouch, O., 2007. Persuasive recommendation: exploring serial position effects in knowledge-based recommender systems. In: De Kort, Y., IJsselsteijn, W., Midden, C., Eggen, B., Fogg, B.J. (Eds.), 2nd International Conference of Persuasive Technology (Persuasive 2007). Lecture Notes in Computer Science, vol. 4744. Springer, Palo Alto, CA, pp. 283–294. Felfernig, A., Gula, B., Leitner, G., Maier, M., Melcher, R., Teppan, E., 2008. Persuasion in knowledge-based recommendation. In: Oinas-Kukkonen, H., Hasle, P.F.V., Harjumaa, M., Segerståhl, K., Øhrstrm, P. (Eds.), Persuasive Technology, 3rd International Conference (PERSUASIVE 2008). Lecture Notes in Computer Science, vol. 5033. Springer, Oulu, Finland, pp. 71–82. Felfernig, A., Schubert, M., Friedrich, G., Mandl, M., Mairitsch, M., Teppan, E., 2009. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA, pp. 791–796. Felfernig, A., Zehentner, C., Blazek, P., 2011. CoreDiag: eliminating redundancy in constraint sets. In: 22nd International Workshop on Principles of Diagnosis (DX’2011), Murnau, Germany, pp. 219–224. Felfernig, A., Schubert, M., Zehentner, C., 2012. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 26 (1), 53–62. Felfernig, A., Reiterer, S., Stettinger, M., Reinfrank, F., Jeran, M., Ninaus, G., 2013a. Recommender systems for configuration knowledge engineering. In: Workshop on Configuration. Vienna, Austria, pp. 51–54. Felfernig, A., Schippel, S., Leitner, G., Reinfrank, F., Isak, K., Mandl, M., Blazek, P., Ninaus, G., 2013b. Automated repair of scoring rules in constraint-based recommender systems. AI Communications 26 (2), 15–27. Felfernig, A., Schubert, M., Reiterer, S., 2013c. Personalized diagnosis for over-constrained problems. In: 23rd International Conference on Artificial Intelligence, Peking, China, pp. 1990–1996. Felfernig, A., Reiterer, S., Reinfrank, F., Ninaus, G., Jeran, M., 2014. Conflict detection and diagnosis in configuration. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 73–87 (Chapter 7). Friedrich, G., Ryabokon, A., Falkner, A.A., Haselböck, A., Schenner, G., Schreiner, H., 2011. (Re)configuration based on model generation. In: Second Workshop on Logics for Component Configuration (LoCoCo 2011), Perugia, Italy, pp. 26–35.

106

CHAPTER 8 User Interfaces for Configuration Environments

Friedrich, G., Jannach, D., Stumptner, M., Zanker, M., 2014. Knowledge engineering for configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 139–155 (Chapter 11). Grabner-Kräuter, S., Kaluscha, E., 2003. Empirical research in on-line trust: a review and critical assessment. International Journal of Human-Computer Studies 58 (6), 783–812. Heiskala, M., Anderson, A., Huhtinen, V., Tiihonen, J., Martio, A., 2003. A tool for comparing configurable products. In: 18th International Joint Conference on Artificial Intelligence – Workshop on Configuration. AAAI, Acapulco, Mexico, pp. 64–69. Hotz, L., Wolter, K., 2014. Smarthome configuration model. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 121–135 (Chapter 10). Hotz, L., Felfernig, A., Stumptner, M., Ryabokon, A., Bagley, C., Wolter, K., 2014. Configuration Knowledge Representation and Reasoning. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 41–72 (Chapter 6). Konstan, J., Miller, B., Maltz, D., Herlocker, J., Gordon, L., Riedl, J., 1997. Grouplens: applying collaborative filtering to usenet news full text. Communications of the ACM 40 (3), 77–87. Mandl, M., Felfernig, A., Teppan, E., 2014. Consumer decision-making and configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 181–190 (Chapter 14). Mittal, S., Frayman, F., 1989. Towards a generic model of configuration tasks. 11th International Joint Conference on Artificial Intelligence (IJCAI-89), Detroit, Michigan, vol. 2 pp. 1395–1401. Piller, F.T., Blazek, P., 2014. Core capabilities of sustainable mass customization. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 107–120 (Chapter 9). Pine, B.J., 1999. Mass Customization: The New Frontier in Business Competition. Harvard Business School Press. Randall, T., Terwiesch, C., Ulrich, K., 2005. Principles for user design of customized products. California Managament Review 47 (4), 1–18. Rogoll, T., Piller, F.T., 2004. Product configuration from the customer’s perspective: A comparison of configuration systems in the apparel industry. In: International Conference on Economic, Technical and Organisational aspects of Product Configuration Systems (PETO 2004). Lyngby, Kopenhagen, Denmark, pp. 179–199. Sabin, D., Weigel, R., 1998. Product configuration frameworks - a survey. IEEE Intelligent Systems 13 (4), 42–49. Simonson, I., 2003. Determinants of Customer’s Responses to Customized Offers: Conceptual Framework and Research Propositions. Stanford GSB Working Paper No. 1794. Sinz, C., Haag, A., Narodytska, N., Walsh, T., Gelle, E., Sabin, M., Junker, U., O’Sullivan, B., Rabiser, R., Dhungana, D., Grünbacher, P., Lehner, K., Federspiel, C., Naus, D., 2007. Configuration. IEEE Intelligent Systems 22 (1), 78–90. Tiihonen, J., Anderson, A., 2014. VariSales. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledgebased Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 309–318 (Chapter 26). Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406. Tiihonen, J., Heiskala, M., Anderson, A., Soininen, T., 2013. WeCoTin – a practical logic-based sales configurator. AI Communications 26 (1), 99–131. Tiihonen, J., Felfernig, A., Mandl, M., 2014. Personalized configuration. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 167–179 (Chapter 13). Winterfeldt, D., Edwards, W., 1986. Decision analysis and behavioral research. Cambridge University Press, London, UK.

CHAPTER

9

Core Capabilities of Sustainable Mass Customization

Frank T. Piller* and Paul Blazek† * RWTH

Aachen, Aachen, Germany Vienna, Austria

† cyLEDGE,

Abstract: The goal of mass customization is to efficiently provide customers with what they want, when they want it, at an affordable price. Realizing this promise demands from the perspective of process design the integration of customers into the value chain of the manufacturer. Here, configuration processes play a crucial role to manage this task by providing customers support and navigation in co-designing their individual product or service. But this capability of “choice navigation,” enabled by modern configuration systems, is just one of three strategic capabilities of mass customization. This chapter explains why configuration systems are playing a crucial role in meeting the particular demands of each individual customer and addresses the fundamental capabilities of sustainable mass customization: solution space development, the design of robust processes, and choice navigation.

9.1 Introduction The objective of mass customization (MC)1 is to deliver goods and services that meet individual customers’ needs with near mass production efficiency (Tseng and Jiao, 2001). Product configuration systems that are also referred to as “co-design toolkits” (Franke and Piller, 2003, 2004) are the traditional tools in mass customization that enable the individual customer to specify product features (Sabin and Weigel, 1998). Configuration systems are also known as configurators, choice boards, design systems, toolkits, or co-design platforms (Hvam et al., 2008; Salvador and Forza, 2007). They are responsible for guiding the user through the preference elicitation process. Whenever the term configurator or configuration system is quoted in literature, for the most part, it is used in a technical sense, usually addressing a software tool. The success of such a tool, however, is by no means defined solely by its technological capabilities, but also by its integration into the sales environment, its ability to allow for learning, its ability to provide experience and process satisfaction, and its integration into the brand concept. Configuration systems for mass customization have to be differentiated from configuration systems for complex technical requirements (Stumptner, 1997). The latter are expert tools that often need usage trainings and are mainly used by technical experts, whereas MC product configurators deal with company-to-customer interaction and cooperation (Khalid and Helander, 2003; Tseng et al., 2003). Already in 1991, Udwadia and Kumar were envisioning customers and manufacturers becoming coconstructors (i.e., co-designers) of those products intended for each customer’s individual use. In their 1 This

chapter combines the argumentation developed in two earlier publications: Piller (2008) and Salvador et al. (2009).

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00009-8 © 2014 Elsevier Inc. All rights reserved.

107

108

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

view, co-construction would occur when customers have only a nebulous sense of what they want. Without a deep involvement of the customers, the manufacturer would be unable to cater to each individual product demand adequately. After this seminal publication (Udwadia and Kumar, 1991), computer technology, particularly the capacity to simulate potential product designs before a purchase, has strongly enabled co-design technologies (Haug and Hvam, 2007; Ulrich et al., 2003). This type of collaboration is also known as collaborative customization (Gilmore and Pine, 1997). In collaborative customization, the manufacturer and customer work together to identify and satisfy the customer’s needs via a system that allows easy articulation of exact requirements (i.e., design, fit, and function of a product). AndersonConnell et al. (2002) used the term co-design to describe a collaborative relationship between consumers and manufacturers in which, via a process of interaction between a design manager and a consumer, a product is designed according to the consumer’s specification and based on the existing manufacturing components. Sophisticated configurators have been the enabling force in various domains; in mass customization they have been one of the efficiency drivers for the concept of bringing together custom manufacturing and mass production through shifting the time-consuming demands identification process to the customers themselves. Moving the responsibility of creating individualized products to the customer comes along with a set of requirements that have to be fulfilled in order to avoid confusion. To understand the nature and complexity of required configuration functionalities, it is necessary to take a closer look at the capabilities that play a role when dealing with product customization. Companies that successfully implemented a mass customization strategy have built competences around a set of three core capabilities that are driving a sustainable mass customization business. The key to profiting from mass customization is to see it as a set of organizational capabilities that can supplement and enrich an existing system. While specific answers on the nature and characteristics of these capabilities are clearly dependent on industry context or product characteristics, three fundamental groups of capabilities determine the ability of a company to mass customize. These capabilities, Solution Space Development, Robust Process Design, and Choice Navigation, are derived from work by Salvador et al. (2009, 2008). The methods behind these capabilities are often not new. Some of them have been around for years. But successful mass customization demands that these methods be combined into capabilities in a meaningful and integrated way, to design a value chain that creates value from serving individual customers differently.

9.2 Solution Space Development A mass customizer must first identify the idiosyncratic needs of its customers, specifically, those product attributes along which customer needs diverge the most. This is in contrast to a mass producer, who generally tries to focus on serving universal needs, ideally shared by all the target customers. Once that information is known and understood, a business can define its “solution space” clearly delineating what it will offer and what it will not. This space determines what universe of benefits an offer is intended to provide to customers and then what specific permutations of functionality can be provided within that universe (Pine, 1995).

9.2 Solution Space Development

109

9.2.1 Options for Customization From the perspective of product development, value by customization can be achieved via three design features of a product (or service), any of which can become the starting point for customization: (1) the fit (measurements), (2) the functionality, and (3) the form (style and aesthetic design) of an offering (Piller, 2005). These are generic dimensions that match the demand of a customer with regard to an offering. Along these three dimensions, heterogeneities of demand from a customer perspective can be derived. The solution space should represent choice options for those dimensions where customer heterogeneities matter in a particular case. Fit and comfort (measurements). The traditional starting point for customization in consumer good markets is to fit a product according to the measurements provided by the client; for example, body measurements or the dimensions of a room or other physical objects. Market research identifies better fit as one of the strongest arguments in favor of mass customization. Especially with products that are directly related to the human body it is one of the most difficult dimensions to achieve, demanding complex systems to gather the customers’ proportions exactly and to transfer them into a product that has to be based on a parametric design. This often calls for a total product redesign and the costly development of flexible product architectures with enough slack to accommodate all possible fitting demands of the customer community. In sales, for example, expensive 3D scanners are needed, which in turn demands highly qualified sales staff to operate them (Berger et al., 2005). Achieving fit with non-human-centered products (e.g., made-to-measure entrance doors) might not be as demanding in the initial data gathering, however, the needed flexibility in the product architecture with all relevant rules requires an accurate knowledge of all product parameters. Functionality. Functionality addresses issues such as speed selection, precision, power, cushioning, output devices, interfaces, connectivity, upgradeability, and similar technical attributes of an offering according to the requirements of the client. This is the traditional starting point for customization in industrial markets, where machines, for example, are adjusted to fit in with an existing manufacturing system, or components are produced according to the exact specifications of their buyers. In manufacturing, however, the growing share of software control in many products enables the customizability of functional components more easily. Form (style and aesthetic design). This dimension relates to modifications aiming at the sensual or the visual senses; for example, selecting colors, styles, applications, cuts, or flavors. Many mass customization offerings in business-to-consumer e-commerce are based on the possibility of co-designing the outer appearance of a product. This kind of customization is often relatively easy to implement in manufacturing, especially if digital printing technology can be applied. The desire for a particular outer appearance is often inspired by fashions, peers, role models, and such as the individual’s desire is to copy and to adopt these trends. Along this line, the construct of consumers’ need for uniqueness has been discussed in the psychological marketing literature (Tepper et al., 2001). Consumers acquire and display their unique material possessions for the purpose of feeling differently from other people. Mass customization can be a further means to express their uniqueness, where consumers can design products according to their own personal specifications in order to vary from the rest. To illustrate these three dimensions (fit, functionality, and form), consider the example of shoes. Fit is mostly defined by the last on which the shoe is formed, but also by the design of the uppers, insole, and outsole. Style is an option for influencing the aesthetic design of the product, for example, the colors

110

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

of the leathers, or patterns. A shoe’s functionality can be defined by its cushioning, heel form, or cleat structure. To understand the large variety of configurable products that are available online, we recommend a closer look at the benchmark study “The Customization 500” (Walcher and Piller, 2012) and at the “Configurator Database Report 2013” (Blazek et al., 2013).

9.2.2 Methods for Solution Space Definition To define the solution space, the company has to identify those needs where customers are different, and where they care about these differences. Matching the options represented by the solution space with the needs of the targeted market segment is a major success factor of mass customization (Hvam et al., 2008). The core requirement at this stage is to access “customer need information”; that is information about preferences, needs, desires, satisfaction, and motives of customers and users of the product or service offering. Need information builds on an in-depth understanding and appreciation of the customers’ requirements, operations, and systems. Spotting untapped differences across customers is not an easy task, because information about unfulfilled customer needs is “sticky”—that is, difficult to access and codify for the solutions provider (von Hippel, 1998). Understanding heterogeneous customer needs in terms of identifying differentiating attributes, validating product concepts, and collecting customer feedback can be a costly and complex endeavor, but several approaches can help. The first is to engage in conventional market research techniques; that is to meticulously gather data from representative customers on a chosen market sector. To reduce the risk of failure, need-related information from customers is integrated iteratively at many points in the new product development process (Dahan and Hauser, 2002; Griffin and Hauser, 1993). The manufacturer selects and surveys a group of customers to obtain information on needs for new products, analyzes the data, develops a responsive product idea, and screens this idea against customer preferences (needs) and purchasing decisions. This model is dominating especially in the world of consumer goods, where market research methodology such as focus groups, conjoint analysis, customer surveys, and analyses of customer complaints is used regularly to identify and evaluate customer needs and desires. A second approach companies can use to define their solution space is to provide customers with toolkits for user co-creation (Franke and Piller, 2004; von Hippel and Katz, 2002). These are software design tools similar to CAD systems, but with an easy-to-use interface and a library of basic modules and functionalities. With these toolkits, customers can by themselves translate their preferences directly into a product design, highlighting unsatisfied needs during the process. The resulting information can then be evaluated and potentially incorporated by the company into its solution space. Third, in developing their solution space (see Table 9.1) companies can employ some form of “customer experience intelligence”; that is to apply methods for continuously collecting data on customer transactions, behaviors, or experiences and analyzing that information to determine customer preferences. This also includes incorporating data not just from customers, but also from people who might have taken their business elsewhere. Consider, for example, information about products that someone has evaluated, but did not order. Such data can be obtained from log files generated by the browsing behavior of people using online configurators (Piller et al., 2004; Rangaswamy and Pal, 2003; Squire et al., 2004). By systematically analyzing that information, managers can learn much about customer

9.2 Solution Space Development

111

Table 9.1 Solution space definition approaches. Name

Description

References

Market research techniques

Selecting and surveying a group of customers to obtain information on needs for new products with the help of conventional market research approaches. Offering software tools that enable customers to translate their preferences directly into a product design and identifying unsatisfied needs during the process. Continuously collecting data on all transactions, behaviors, or experiences not only from customers but from all users and analyzing that information to determine preferences.

Dahan and Hauser (2002), Griffin and Hauser (1993)

Toolkits for user co-creation

Customer experience intelligence

Franke and Piller (2004), von Hippel and Katz (2002)

Piller et al. (2004), Rangaswamy and Pal (2003), Squire et al. (2004)

preferences, ultimately leading to a refined solution space. A company could, for instance, eliminate options that are rarely explored or selected, and it could add more choices for the popular components. In addition, customer feedback can even be used to improve the very algorithms that a particular application deploys.

9.2.3 Modular Product Architectures Once the relevant options to be represented in a solution space have been identified, these have to be transferred into a product architecture that includes the configuration model (Felfernig, 2007). It is important to note that mass customization does not mean to offer limitless choice, but to offer choice that is restricted to options that are already represented in the production system. In the case of digital goods (or components), customization possibilities may be infinite. In the case of physical goods, however, they are limited and may be represented by a modular product architecture. Modularity is an important part of many mass customization strategies (Duray, 2002; Gilmore and Pine, 1997; Kumar, 2005; Piller, 2005; Salvador, 2007). Each module provides one or more well-defined functions of the product and is available in several options that deliver a different performance level for the function(s) the product is intended to serve. In order to manage the additional costs of variety, product families of similar or identical units can be formed. The product family approach has been recognized as an effective means to accommodate an increasing product variety across diverse market niches while still being able to achieve economies of scale (Tseng and Jiao, 2001; Zhang and Tseng, 2007). In addition to leveraging the costs of delivering variety, product family design can reduce development risks by reusing proven elements in a firm’s activities and offerings. Setting the modular product family structure of a mass customization system, and thus its solution space, becomes one of the foremost competitive capabilities of a mass customization company.

112

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

9.3 Robust Process Design A core idea of mass customization is to ensure that an increased variability in customers’ requirements will not significantly impair the firm’s operations and supply chain (Pine et al., 1993). This can be achieved through robust process design, which is the capability to reuse or recombine existing organizational and value-chain resources to deliver customized solutions with high efficiency and reliability. A successful mass customization system hence is characterized by stable, but still flexible, responsive processes that provide a dynamic flow of products (Badurdeen and Masel, 2007; Pine, 1995; Salvador et al., 2004; Tu et al., 2001). Value creation within robust processes is the major differentiation of mass customization versus conventional (craft) customization. Traditional (craft) customizers often reinvent not only their products, but also their processes for each individual customer. Mass customizers use stable processes to deliver high-variety goods (Pine et al., 1993), which allows them to achieve near mass production efficiency, but it also implies that the customization options are somehow limited. Customers are being served within a list of predefined options or components, the company’s solution space. The core objective of robust process design is to prevent or counterbalance the additional cost resulting from the flexibility a company needs to build in order to serve its customers individually. We can differentiate two sources of additional cost of flexibility (Su et al., 2005): (1) increased complexity and (2) increased uncertainty in business operations, which by implication results in higher operational cost. Methods to establish robust processes. A primary mechanism to create robust processes in mass customization is the application of delayed product differentiation (postponement). Delayed product differentiation refers to partitioning the supply chain into two stages (Yang and Burns, 2003; Yang et al., 2004). A standardized portion of the product is produced during the first stage, while the differentiated portion of the product is produced in the second stage, based on customer preferences that were expressed in an order. The success of delayed product differentiation is a direct manifestation of the fact that most companies offer a portfolio of products that consists of families of closely related products that differ from each other in a limited number of differentiated features. An example of delayed product differentiation in the automotive industry would be to send a standard version of the car (a stripped or partially equipped version) to dealers and then allow the dealer to install, on the basis of customer-specific requests, options such as a CD/DVD player, the interior leather or fabric, and the cruise control system. Prior to the point of differentiation, product parts are reengineered in such a way that as many parts or components as possible are common to each configuration. Cost savings result from the risk-pooling effect and reduction in inventory stocking costs (Yang et al., 2004). While postponement starts with the design of the offerings, another possibility to achieve robust processes is through flexible automation (Koste et al., 2004; Tu et al., 2001; Zhang et al., 2003). Although the words “flexible” and “automation” might have been contradictory in the past, that’s no longer the case. In the automotive industry, robots and automation are compatible with high levels of versatility and customization. Even process industries (e.g., pharmaceuticals, food, and so on), once synonymous with rigid automation and large batches, nowadays enjoy levels of flexibility once considered unattainable. Similarly, many intangible goods and services also lend themselves to flexible automated solutions, oftentimes based on the Internet. A complementary approach to flexible automation is process modularity, which can be achieved by thinking of operational and value-chain processes as segments, each one linked to a specific source

9.4 Choice Navigation

113

of variability in the customers’ needs (Pine et al., 1993). As such, the company can serve different customer requirements by appropriately recombining the process segments, without the need to create costly ad-hoc modules (Zhang et al., 2003). BMW’s Mini factory, for instance, relies on individual mobile production cells with standardized robotic units. BMW can integrate the cells into an existing system in the plant within a few days, thus enabling the company to quickly adapt to unexpected swings in customer preferences without extensive modifications of its production areas.

9.4 Choice Navigation 9.4.1 Paradox of Choice A mass customizer must support customers in identifying their own needs and creating solutions while minimizing complexity and the burden of choice. When a customer is exposed to a myriad of choices, the cost of evaluating those options can easily outweigh the additional benefit from having so many alternatives. The resulting syndrome has been called the “paradox of choice” (Schwartz, 2004), in which too many options can actually reduce customer value instead of increasing it (Desmeules, 2002; Huffman and Kahn, 1998). In such situations, customers might postpone their buying decisions and, worse, classify the vendor as difficult and undesirable. Research in marketing has addressed this issue in more detail and has found that the perceived cognitive cost is one of the largest hurdles toward a larger adaption of mass customization from the consumer perspective (Dellaert and Stremersch, 2005). To avoid that, companies have to provide means of choice navigation to simplify the ways in which people explore their offerings.

9.4.2 Effective Support of Interaction When looking at the interaction patterns offered by configurators it becomes obvious that the different types with their different goals and solution spaces must have specific characteristics in defining the way the interface to the customer has to look like (see also Leitner et al., 20142 ). The range of product configurators spans from simple Select-to-order (STO) and Pick-to-order (PTO) configurators, to currently massive growing Assemble-to-order (ATO) and Configure-to-order (CTO) configuration systems, up to sophisticated Make-to-order (MTO) and high-end Engineer-to-order (ETO) solutions that bridge the field of product configurators with the field of user innovation configurators (see Table 9.2). The more complex the purpose of a configuration system is, the lower is the similarity between individual systems. Nevertheless a number of findings shed light on recurring patterns, which are the basis for more general interaction rules. It seems to be clear that the success of a configuration system is not only defined by its technological capabilities but by many more factors such as its ability to allow learning by doing, to add experience effects, and to initiate process satisfaction (Franke and Piller, 2003). As almost any interaction throughout the customer buying cycle might take place via online channels, it is important to see the information delivery aspects that play an enabling and an accompanying role to the configuration process itself. According to Totz and Riemer (2001), information has to be communicated in a clear and sufficient way to eliminate uncertainties when configuring products. 2 Chapter

8.

114

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

Table 9.2 Types of product configurators. Type Select-to-order (STO)

Description

The customer selects all needed components of a product. There are no component dependencies. Pick-to-order (PTO) The customer picks the components of a product and takes care himself of the dependencies without support of the configurator. Assemble-to-order (ATO) The configurator matches prefabricated components considering component dependencies. Configure-to-order (CTO) The configurator supports the customer in selecting the components that fit to each other based on a modular system. Make-to-order (MTO) The configurator allows the customer to define specific parameters based on product rules. Manufacturing takes place after order. Engineer-to-order (ETO) Very high level of configuration freedom. New components and new rules might be required to satisfy the configuration needs of the customer.

Complexity low low medium medium medium–high

high

Information on available products and services and the configuration possibilities has to be provided. The user has to be informed about prices, delivery, and after-sales conditions. The producer has to provide information on the company’s capabilities as well as a brand and shopping experience. Furthermore the proposition of the most suitable products and services can be helpful to reduce uncertainties. What makes information delivery tricky is that there are different ways to represent a product to the customer. Salvador and Forza (2007) point out that descriptions of the same product may focus on different degrees of abstraction, like focusing on the product performance, on the product functions, or on the physical product components. Increasing the ability of the customer to understand the offerings by using an approach, a language, and tone that is fitting his/her cognitive expectations results in the reduction of the configuration complexity; also diminishing the overall information load for the customer should be part of this simplification strategy. Rogoll and Piller (2004) state that usability is directly responsible for the success or failure of a configuration system. Important usability aspects are operability and self explanation (i.e., intuitive handling and navigation), orientation (i.e., transparency and traceability of the application structure), individual access on information (i.e., information has to be accessible in different ways such as textual, visual, alphabetical, etc.), loading time (i.e., the application must not take too long for loading or actualizing each configuration step), and support (i.e., the support functionality has to be able to deal with potential problems occurring in the configuration process). Besides these usability aspects there are additional parameters that strongly influence the perceived quality of a product configuration system: visual realism (i.e., how realistic is the visualization of the product configuration process), creativity (i.e., the degree and limitations of creational freedom while configuring the product), enjoyment (i.e., how much fun, delight, pleasure, entertaining and interesting the configuration process is), choice options (i.e., the perceived degree of given choice options in the solution space; Walcher and Piller, 2012). Convincing the customer to purchase under uncertainty and meeting the specific needs of each customer well enough remains the quest to be mastered.

9.4 Choice Navigation

115

9.4.3 Attainable Benefits and Process Satisfaction Choice navigation not only avoids complexity of choice and the negative effects of variety from the customers’ perspective; offering choice to customers in a meaningful way, on the contrary, can provide new profit opportunities (Franke and Schreier, 2010). Research has shown that up to 50% of the additional willingness to pay for customized (consumer) products can be explained by the positive perception of the co-design process itself (Franke and Piller, 2004; Franke and Schreier, 2010; Merle et al., 2010; Schreier, 2006). Products co-designed by customers may also provide symbolic (intrinsic and social) benefits for them, resulting from the actual process of co-design rather than its outcome. Schreier (2006) quotes, for example, a pride-of-authorship effect. This effect relates to the desire for uniqueness, as discussed before, but here it is based on a unique task and not the outcome. In addition to enjoyment, task accomplishment has a sense of creativity. Participating in a co-design process may be considered a highly creative problem-solving process by the individuals engaged in this task, thus becoming a motivator to purchase a mass-customized product. Communicating this created product individuality is supported by a growing number of social media applications (e.g., Facebook, Twitter, Pinterest, YouTube, Google Plus). The integration of customers in social networks is consequently another field, which recent papers (Blazek et al., 2012; Piller et al., 2012) focus on. An important precondition for customer satisfaction through co-design is that the process itself should be successful. The customer has to be capable of performing the task. This competency issue involves flow, a construct often used by researchers to explain how customer participation in a process increases satisfaction (Csíkszentmihályi, 1990). Flow is the process of optimal experience achieved when motivated users perceive a balance between their skills and the challenge at hand during an interaction process (Novak et al., 2000). Interacting with a co-design toolkit may lead to this state, as recent research in marketing indicates (Dellaert and Stremersch, 2005; Franke et al., 2008; Fuchs et al., 2010). Accordingly, recent research has provided several design guidelines that should facilitate this effect of process satisfaction (Dellaert and Dabholkar, 2009; Franke et al., 2009; Randall et al., 2005).

9.4.4 Learning Relationship The interaction between the manufacturer and the customer that is underlying a co-design process offers further possibilities for building loyalty and lasting customer relationships. Once a customer has successfully purchased an individual item, the knowledge acquired by the manufacturer represents a possible barrier against switching to other suppliers. Reordering becomes much easier for the customers. Consider, as an example, the case of Adidas, the large manufacturer of sporting goods (Berger et al., 2005). In 2001, the company introduced its mass customization program “mi adidas,” offering custom sport shoes with regard to fit, functionality, and aesthetic design. The process starts with a customer who wants to buy personalized running shoes for around $150. The more customers tell the vendor about their likes and dislikes during the integration process, the better the chance of a product being created that meets the customers’ exact needs at the first try. The manufacturer can draw on detailed information about the customer for the next sale, ensuring that the service provided becomes quicker, simpler, and more focused. The information status is increased and more finely tuned with each additional sale. When Adidas entered into a learning relationship with its customers, it increased the revenues from each customer because, in addition to the actual product benefits, it simplified the purchasing decision, so that the customer keeps coming back. By aggregating information from a segment of individual customers, Adidas also gains valuable market research knowledge. As a result, new products for the

116

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

mass market segment can be planned more efficiently, and market research is more effective because of unfiltered access to data on market trends and customers’ needs. This is of special benefit to those companies that unite large-scale make-to-stock production with tailored services. Mass customization can thus become an enabling strategy for higher efficiency of a mass production system. This learning relationship may lead to new cost-saving potential (Piller et al., 2004), based on better access to knowledge about the needs and demands of the customer base (Kotha, 1995; Squire et al., 2004). This includes (1) the reduced need for forecasting product demand (or at least the possibility to focus forecasting), (2) reduced or eliminated inventory levels of finished goods, (3) reduced product returns, (4) reduced obsolescence or antiquated fashion risks, and (5) the prevention of lost sales if customers cannot find the product in a store that fits their requirements and, thus, allocate the purchasing budget to another item. The savings from these effects can be huge. Forrester Research estimated that the US automotive industry could save up to $3,500 per vehicle by moving from its current build-to-stock model to a build-to-order system (Reichwald and Piller, 2009).

9.4.5 Advanced Methods of Choice Navigation The application of toolkits for customer co-design may be the most used approach to help customers navigate choice in a mass customization system. But a number of other approaches exist, too. One effective approach is what we labeled assortment matching (Salvador et al., 2009), in which software automatically builds configurations for customers by matching models of their needs with characteristics of existing sets of options. Then customers only have to evaluate the predefined configurations, which saves considerable effort and time in the search process. Using special software, for example, customers at Sears.com can build avatars of themselves by selecting different body types, hair styles, facial characteristics and so on. From that information, the system can then recommend items out of the vast assortment of an online merchant. But customers might not always be ready to make a decision after they’ve received recommendations (see also Tiihonen et al., 20143 ). They might not be sure about their real preferences, or the recommendations may not appear to fit their needs. In such cases, combining a recommendation system with a co-design toolkit is a perfect solution. Consider online shoppers at 121Time.com, a leading provider of mass-customized Swiss watches. Customers in the watch market might have a general idea of what they want, but while using an online configurator to play around with various options, combining colors and styles, they can actually see how one choice influences another and affects the entire look of a watch. Through that iterative process, they learn about their own preferences—important information that is then represented in subsequent configurations. A number of companies are engaging in even more innovative and drastic approaches to choice navigation. Choice navigation has been completely automated in recent products that understand how they should adapt to the user and then reconfigure themselves accordingly. Equipped with so-called embedded configuration capability, the products paradoxically become standard items for the manufacturer while the user experiences a customized solution. This can be regarded as a postponement configuration strategy where the user can be enabled to modify the product after it has been manufactured and has reached the user domain, offering an embedded product “smartness.” Imagine products with 3 Chapter

13.

References

117

a high feature load (e.g., cars) where the customer uses ICT interfaces and sensors to create a feature configuration that better suits his/her preferences and needs (Piller et al., 2010).

9.5 Conclusion Mass customization can be regarded as a response to today’s opportunities of heterogeneous demands and the need for companies to become truly customer-centric. While traditionally mass customization has been associated with flexible manufacturing technology and the development of modular product architectures, we have shown in this chapter that mass customization cannot be realized without conceptualizing, designing, and implementing a configurator. Besides product modeling and the integration of the configuration solution into the IT systems of the firm, the task in implementing such a configuration system is to offer an appropriate user interface that is easy to understand without training, intuitive to operate, providing support in navigating complex choice sets, guiding the user to find a fitting solution, and that at the same time is also fun to operate, leading to a sustaining process satisfaction of the customer. The latter has been shown to be a core factor of success, especially in BtoC mass customization markets. But as argued in this chapter, in the end mass customization requires a business to develop three fundamental capabilities; configuration system design is not enough. Only when the solution space is defined correctly and robust processes are in place, choice navigation via configuration toolkits will lead to sustainable success. Overall, mass customization should be considered a journey rather than a destination. There is not a perfect state of mass customization (Salvador et al., 2009). What matters to most companies instead is to continuously increase their overall capabilities to define the solution space, to design robust processes, and to help customers navigate through available choices. A company offering standard goods may already profit tremendously from just implementing better, say, choice navigation capabilities to match diverse requests of customers not familiar with the product category with options from an existing assortment of standard products. We have called this understanding mass customization thinking (Piller, 2005). It provides a way to profit from heterogeneities of a firm’s customers. Mass customization thinking means to build the three capabilities and to apply them for designing a value chain that creates value from serving customers individually. Here we call for future research to investigate these relationships more closely, and also to study more closely how configurators have to be embedded within other capabilities.

References Anderson-Connell, L.J., Ulrich, P.V., Brannon, E.L., 2002. A consumer-driven model for mass customization in the apparel market. Journal of Fashion Marketing and Management 6 (3), 240–258. Badurdeen, F., Masel, D., 2007. A modular minicell configuration for mass customization manufacturing. International Journal of Mass Customization 2 (1–2), 39–56. Berger, C., Möslein, K., Piller, F.T., Reichwald, R., 2005. Co-designing modes of cooperation at the customer interface: learning from exploratory research. European Management Review 2 (1), 70–87. Blazek, P., Kolb, M., Partl, M., Streichsbier, C., 2012. The usage of social media applications in product configurators. International Journal of Industrial Engineering and Management 3 (4), 179–183.

118

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

Blazek, P., Partl, M., Streichsbier, C., 2013. Configurator Database Report 2013. Tech. rep., Raleigh, NC. . Csíkszentmihályi, M., 1990. Flow: The Psychology of Optimal Experience. Harper & Row, New York. Dahan, E., Hauser, J., 2002. The virtual customer. Journal of Product Innovation Management 19 (5), 332–353. Dellaert, B.G., Dabholkar, P., 2009. Increasing the attractiveness of mass customization: the role of complementary online services and range of options. International Journal of Electronic Commerce 13 (3), 43–70. Dellaert, B.G.C., Stremersch, S., 2005. Marketing mass customized products: striking the balance between utility and complexity. Journal of Marketing Research 42 (2), 219–227. Desmeules, R., 2002. The impact of variety on consumer happiness: marketing and the tyranny of freedom. Academy of Marketing Science Review 12, 1–18. Duray, R., 2002. Mass customization origins: mass or custom manufacturing? International Journal of Operations & Production Management 22 (3), 314–328. Felfernig, A., 2007. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management 54 (1), 41–56. Franke, N., Piller, F.T., 2003. Key research issues in user interaction with configuration toolkits in a mass customization system. International Journal of Technology Management 26, 587–599. Franke, N., Piller, F.T., 2004. Value creation by toolkits for user innovation and design: the case of the watch market. Journal of Product Innovation Management 21 (6), 401–415. Franke, N., Schreier, M., 2010. Why customers value self-designed products: the importance of process effort and enjoyment. Journal of Product Innovation Management 27 (7), 1020–1031. Franke, N., Keinz, P., Schreier, M., 2008. Complementing mass customization toolkits with user communities: how peer input improves customer self-design. Journal of Product Innovation Management 25 (6), 546–559. Franke, N., Keinz, P., Steger, C., 2009. Testing the value of customization: when do customers really prefer products tailored to their preferences? Journal of Marketing 73 (5), 103–121. Fuchs, C., Schreier, M., Prandelli, E., 2010. The psychological effects of empowerment strategies on consumers’ product demand. Journal of Marketing 74 (1), 65–79. Gilmore, J.H., Pine, B.J., 1997. The four faces of mass customization. Harvard Business Review 75 (1), 91–101. Griffin, A., Hauser, J., 1993. The voice of the customer. Marketing Science 12 (1), 1–27. Haug, A., Hvam, L., 2007. The modeling techniques of a documentation system that supports the development and maintenance of product configuration systems. International Journal of Mass Customization 2 (1–2), 1–18. Huffman, C., Kahn, B., 1998. Variety for sale: mass customization or mass confusion. Journal of Retailing 74 (4), 491–513. Hvam, L., Mortensen, N., Riis, H., 2008. Product Customization. Springer, Heidelberg, Berlin. Khalid, H., Helander, M., 2003. Web-based do-it-yourself product design. In: Tseng, M., Piller, F.T. (Eds.), The Customer Centric Enterprise: Advances in Mass Customization and Personalization. Springer, New York, pp. 247–266. Koste, L., Malhotra, M.K., Sharma, S., 2004. Measuring dimensions of manufacturing flexibility. Journal of Operations Management 22 (2), 171–196. Kotha, S., 1995. Mass customization: implementing the emerging paradigm for competitive advantage. Strategic Management Journal 16 (S1), 21–42. Kumar, A., 2005. Mass customization: metrics and modularity. International Journal of Flexible Manufacturing Systems 16 (4), 287–312. Leitner, G., Felfernig, A., Blazek, P., Reinfrank, F., Ninaus, G., 2014. User interfaces for configuration environments. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 89–106 (Chapter 8). Merle, A., Chandon, J., Roux, E., Alizon, F., 2010. Perceived value of the mass–customized product and mass customization experience for individual consumers. Production & Operations Management 19 (5), 503–514.

References

119

Novak, T., Hoffmann, D., Yung, Y., 2000. Measuring the customer experience in online environments: a structural modeling approach. Marketing Science 19 (1), 22–42. Piller, F.T., 2005. Mass customization: reflections on the state of the concept. International Journal of Flexible Manufacturing Systems 16 (4), 313–334. Piller, F.T., 2008. Mass customization. In: Wankel, C. (Ed.). 21st Century Management: A Reference Handbook, vol. 1. Sage Publications, pp. 420–430. Piller, F.T., Möslein, K., Stotko, C., 2004. Does mass customization pay? An economic approach to evaluate customer integration. Production Planning & Control 15 (4), 435–444. Piller, F.T., Ihl, C., Steiner, F., 2010. Embedded toolkits for user co-design: a technology acceptance study of product adaptability in the usage stage. In: 43th Hawaii International Conference on System Science (HICSS), Honolulu, HI, CD–ROM, p. 10. Piller, F.T., Vossen, A., Ihl, C., 2012. From social media to social product development: the impact of social media on co-creation of innovation. Die Unternehmung 66 (1), 7–27. Pine, B.J., 1995. Challenges to total quality management in manufacturing. In: Cortada, J.W., Woods, J.A. (Eds.), The Quality Yearbook. McGraw-Hill, New York, pp. 69–75. Pine, B.J., Victor, B., Boynton, A., 1993. Making mass customization work. Harvard Business Review 71 (5), 108–119. Randall, T., Terwiesch, C., Ulrich, K., 2005. Principles for user design of customized products. California Management Review 47 (4), 1–18. Rangaswamy, A., Pal, N., 2003. Introduction: gaining business value from personalization technologies. In: Pal, N., Rangaswamy, A. (Eds.), The Power of One: Gaining Business Value from Personalization Technologies. Trafford Publishing, Victoria, BC, Canada, pp. 1–9. Reichwald, R., Piller, F., 2009. Interactive value creation in the production: individualization and mass customization. Interactive Value Creation: Open Innovation, Individualization and New Forms of Division of Labour, second ed. Gabler Verlag, pp. 263–267 (in German: Interaktive Wertschöpfung in der Produktion: Individualisierung und Mass Customization). Rogoll, T., Piller, F.T., 2004. Product configuration from the customer’s perspective: a comparison of configuration systems in the apparel industry. In: International Conference on Economic, Technical and Organisational Aspects of Product Configuration Systems (PETO 2004), Lyngby, Kopenhagen, Denmark, pp. 179–199. Sabin, D., Weigel, R., 1998. Product configuration frameworks - a survey. IEEE Intelligent Systems 13 (4), 42–49. Salvador, F., 2007. Towards a product modularity construct: literature review and reconceptualization. IEEE Transactions on Engineering Management 54 (2), 219–240. Salvador, F., Forza, C., 2007. Principles for efficient and effective sales configuration design. International Journal of Mass Customization 2 (1–2), 114–127. Salvador, F., Rungtusanatham, M., Forza, C., 2004. Supply-chain configurations for mass customization. Production Planning & Control 15 (4), 381–397. Salvador, F., Rungtusanatham, M., Akpinar, S., Forza, C., 2008. Strategic capabilities for mass customization: theoretical synthesis and empirical evidence. In: Academy of Management Annual Meeting, pp. 1–6. Salvador, F., de Holan, M., Piller, F.T., 2009. Cracking the code of mass customization. MIT Sloan Management Review 50 (3), 70–79. Schreier, M., 2006. The value increment of mass-customized products: an empirical assessment. Journal of Consumer Behavior 5 (4), 317–327. Schwartz, B., 2004. The Paradox of Choice: Why More is Less. HarperCollins, New York. Squire, B., Readman, J., Brown, S., Bessant, J., 2004. Mass customization: the key to customer value? Production Planning & Control 15 (4), 459–471. Stumptner, M., 1997. An overview of knowledge-based configuration. AI Communications 10 (2), 111–126.

120

CHAPTER 9 Core Capabilities of Sustainable Mass Customization

Su, J.C.P., Chang, Y.-L., Ferguson, M., 2005. Evaluation of postponement structures to accommodate mass customization. Journal of Operations Management 23 (3–4), 305–318. Tepper, K., Bearden, W.O., Hunter, G.L., 2001. Consumers’ need for uniqueness: scale development and validation. Journal of Consumer Research 28 (1), 50–66. Tiihonen, J., Felfernig, A., Mandl, M., 2014. Personalized configuration. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 167–179 (Chapter 13). Totz, C., Riemer, K., 2001. The effect of interface quality on success - an integrative approach on mass customization design. In: Tseng, M., Piller, F.T. (Eds.), Proceedings of the 1st World Congress on Mass Customization and Personalization, Hong Kong, China, CD ROM. Tseng, M., Jiao, J., 2001. Mass customization. In: Salvendy, G. (Ed.), Handbook of Industrial Engineering, third ed. Wiley, New York, pp. 684–709 (Chapter 25). Tseng, M., Kjellberg, T., Lu, S.C.-Y., 2003. Design in the new e-commerce era. Annals of the CIRP 52 (2), 509–519. Tu, Q., Vonderembse, M., Ragu-Nathan, T., 2001. The impact of time-based manufacturing practices on mass customization and value to customer. Journal of Operations Management 19 (2), 201–217. Udwadia, F., Kumar, R., 1991. Impact of customer co-construction in product/service markets. International Journal of Technological Forecasting and Social Change 40 (3), 261–272. Ulrich, P., Anderson-Connell, L., Wu, W., 2003. Consumer co-design of apparel for mass customization. Journal of Fashion Marketing and Management 7 (4), 398–412. von Hippel, E., 1998. Economics of product development by users: the impact of “sticky” local information. Management Science 44 (5), 629–644. von Hippel, E., Katz, R., 2002. Shifting innovation to users via toolkits. Management Science 48 (7), 821–833. Walcher, D., Piller, F.T., 2012. The Customization 500 – An International Benchmark Study on Mass Customization and Personalization in Consumer E–Commerce. Tech. rep., Lulu Inc., Raleigh, NC. www.mc-500.com. Yang, B., Burns, N.D., 2003. Implications of postponement for the supply chain. International Journal of Production Research 41 (9), 2075–2090. Yang, B., Burns, N.D., Backhouse, C.J., 2004. Postponement: a review and an integrated framework. International Journal of Operations & Production Management 24 (5), 468–487. Zhang, M., Tseng, M., 2007. A product and process modeling based approach to study cost implications of product variety in mass customization. IEEE Transactions on Engineering Management 54 (1), 130–144. Zhang, Q., Vonderembse, M., Lim, J.-S., 2003. Manufacturing flexibility: defining and analyzing relationships among competence, capability, and customer satisfaction. Journal of Operations Management 21 (2), 173–191.

CHAPTER

Smarthome Configuration Model

10

Lothar Hotz and Katharina Wolter HITeC e.V., University of Hamburg, Hamburg, Germany

Abstract: In this chapter, we present a configuration model taken from a building automation domain. It provides complex aspects of configuration models such as separation of features of a system from realizing system components and domain-dependent workflows for the configuration process.

10.1 Introduction This chapter presents an example of a configuration model of a building automation system. The task in this domain is to compose functionalities of a building, such as controlling sun blinds, regulating air conditioning systems, and monitoring lift facilities. In contrast to the working example introduced in Hotz et al. (2014),1 the domain of building automation systems is more complex. This is due to (1) the higher number of attributed technical component types, (2) a combination of different models representing different aspects of the domain, and (3) the modeling of a configuration workflow. Besides the various knowledge types that are needed for solving configuration problems, the example introduces how to model features and components of the domain. Features are characteristics of products that are visible to the customers (Kang et al., 1990). The composition of the technical components to the actual building automation system makes sure that the features are accomplished (we say the components realize the features). Distinct submodels separate features and components; constraints and relations relate both. Furthermore, the example emphasizes the aspect of modeling the workflow of a configuration process. A workflow takes dependencies between configuration decisions into account and, thus, ensures an effective configuration process. In summary, this complex configuration model example demonstrates the usage of knowledge-based configuration techniques in a technical area. We thereby concentrate on different representation aspects and, thus, do not focus on a complete model.2 In the subsequent sections, we introduce the configuration model for the building automation domain (the Smarthome model). Section 10.2 introduces the terminology used in the Smarthome domain. Section 10.3 introduces the structure of the Smarthome model. Section 10.4 provides the constraints of 1 Chapter

6. though the model demonstrates complex modeling aspects, we base the model on simple assumptions about building automation systems. Further information about such systems can be found in Wolter (2003) and in xinca.com, www.buildingtechnologies.siemens.com, www.kmccontrols.com, highperformancehvac.com. 2 Even

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00010-4 © 2014 Elsevier Inc. All rights reserved.

121

122

CHAPTER 10 Smarthome Configuration Model

the Smarthome model. Section 10.5 illustrates a workflow describing the configuration process for composing a specific building automation system. Section 10.6 summarizes the modeling and representation properties of the Smarthome model. Section 10.7 concludes the chapter.

10.2 Building Automation Systems: Domain Building automation systems (Smarthome systems) provide the equipment for regulating, controlling, and monitoring functionalities of buildings. Depending on the type of buildings, different systems can be automated: lighting systems, solar radiation protection systems, sun blinds, air conditioning systems, heating systems, sanitary facilities, lift facilities, telecommunications systems, or safety systems. Traditionally, if a building contains a number of such subsystems, they are controlled separately. This leads to high effort in wiring and less information exchange between the subsystems. By using a common bus (such as a Local Operating Network, LON3 ) a comprehensive system can be realized that allows a combined control of the subsystems. Devices from distinct areas such as lighting, solar radiation protection, and heating can be controlled via such a bus system. The connected systems can directly communicate with each other. Figure 10.1 gives an example of a configuration of a Smarthome: An office consisting of a corridor, a main office room (e.g., for a head of an office), and a normal office room (e.g., for a clerk) is equipped with building automation facilities. The corridor has a dimmable light. The main office room has sun blinds, which are controlled by: • • • •

•

A wind sensor that triggers the movement of the sun blinds as a means of protecting them against storms. A brightness sensor that triggers a lowering of the sun blinds if it becomes too bright in the room. A temperature sensor that triggers a lowering of the sun blinds if the temperature reaches a specific threshold (it could be too warm in the room and, as a consequence, the sun blinds should be down). A presence detector that activates the brightness sensor if somebody is in the room; that is, the sun blinds are operated solely when a sensor detects a presence in the room (on the premise that if the room is empty, it is not necessary to lower the sun blinds). A switch for allowing manual control of the sun blinds.

Additionally, the main office room has two light groups, one on the ceiling and the other above the desk. The one on the ceiling switches on if somebody is in the room, the one above the desk can be dimmed. The normal office room has one light group, which is a constant light. It ensures constant lighting conditions in a room by taking the natural light into account (i.e., the light of the light group is dimmed according to the daylight in the room). For offices, constant lighting conditions are thus ensured throughout the day. In the office building, there is a control unit that controls centrally the office’s sun blinds and the light groups. Examples of features are the detection of the presence of a person in a room or controlling the sun blinds depending on wind or temperature changes. The configuration task in this domain is to compose the various components according to given desired features of a building automation system. 3 www.lonmark.org

10.3 Configuration Model: Structure

123

Normal office

Main office Temperature Wind Brightness

Presence

Dimmable light

Sensor

Switchable light

Constant light

Sun-blind

Switch

FIGURE 10.1 Example of a Smarthome configuration. The office layout includes a corridor, a normal office, and a main office, as well as components used for the building automation.

10.3 Configuration Model: Structure For separating functional characteristics and technical components of building automation systems, we divide the structure of the Smarthome model (represented by SmartHome) into a feature model (represented by SmartHomeFeature; see Subsection 10.3.1) and a system model (represented by SmartHomeSystem; see Subsection 10.3.2). These models allow a clear separation of functional characteristics (features) of a SmartHome from the components realizing these functionalities (see the association realize in Figures 10.2 and 10.3). The use of SmartHome as an aggregate with two parts, SmartHomeFeature and SmartHomeSystem, combines both aspects in the resulting configuration of one product. Both models exploit configuration knowledge representations as introduced in Hotz et al. (2014)4 and beyond. In particular, the presented models cover the following feature and component-related representation aspects, which will be explained in more detail in the following sections: •

•

Classes are used for representing features and component types. For example, the sun blinds feature is represented with the class SunBlindsFeature and a dimmer is represented with the component type Dimmer. Instances represent selected or inferred features or components for a certain configuration. Instances are not represented in the configuration model but created during the configuration process.

4 Chapter

6.

124

CHAPTER 10 Smarthome Configuration Model

SmartHome

SmartHomeFeature

80 ). Alternative approaches to determine a preferred diagnosis for a set of inconsistent require( 20 ments are discussed in Felfernig et al. (2009, 2013b).

13.4 Research Challenges The integration of personalization and recommendation technologies with configuration systems is still in its infancy. Next, we outline some of the primary topics for future research. Decision phenomena. Psychological theories identify and explain different types of decision biases in consumer decision-making. Consumers are influenced by the format of the information presented and as a consequence use different decision-making strategies in different contexts. This implies that the design of the user interface can have a major impact on the final outcome of the decision-making process. In the context of result pages the focus of our future work is the investigation of the existence of decoy effects (see, e.g., Huber et al., 1982). Decoy effects occur in situations where inferior (low-quality) decoy configurations are presented among other solutions. Effectively, decoys make other solutions ‘look better’. Decoys can trigger a significant shift in the solution selection (purchasing) behavior of users. We are interested in answering questions regarding the upper bound for the number of products such that decoy effects still occur. Furthermore, we are interested in the interrelationship between solution diversity (typically measured by different types of similarity metrics; McSherry, 2004) and the existence of decoy effects. A further question is whether the positioning of the decoy solution in a result set has an impact on the magnitude of the decision bias (decoy effect). Advanced recommendation algorithms. Another topic for future work is to extend existing configuration-supporting recommendation algorithms to take into account structural variation of configurable products. This means to develop algorithms that do not rely on basic CSP representations but are also applicable with more complex, component-oriented product structures (see, e.g., the configuration model in Hotz et al., 2014).11 Furthermore, price and delivery time are often affected by numerous factors such as exact combination of options, and dynamic load of stakeholders such as manufacturing and supply chain. To take these aspects effectively into account when determining recommendations is a topic of future research. Repair actions. If no configuration can be found for a given set of user requirements, numerous alternative combinations of repair actions exist that can resolve the conflict; the number is exponential in the number of requirements (O’Sullivan et al., 2007). A major goal for future work is to extend the approach of Felfernig et al. (2009) by additionally taking into account different types of decision biases that potentially occur in the repair selection process. For example, Kivetz and Simonson (2000) investigated the impact of incomplete information on consumer choice. A series of studies indicates that choosing from sets with missing information can influence consumers’ tastes and purchase decisions (Kivetz and Simonson, 2000). Repair actions can be regarded as incomplete information since repair alternatives typically include only a subset of the product attributes. In this context, we want to investigate whether the inclusion of additional attributes for explanation purposes can have an impact on the repair selection process. 11 Chapter

6.

References

177

Novel approaches to solution search. There exist two major approaches to search a large space of possible solutions. A query-based approach supports the specification of search criteria that have to be taken into account by the final solution; this is the typical approach supported by existing configuration environments. The other alternative to support users is to provide navigation-based interfaces that allow an easy navigation in the solution space. Such a navigation is supported by determining solutions that are similar to the currently presented solution and present this new solution to the user. Navigation-based interfaces are well established in the area of recommender systems (specifically critiquing-based ones). The applicability of these recommendation approaches in configuration scenarios is a major research issue.

13.5 Conclusion In this chapter, we presented a selected set of recommendation strategies that help to personalize the product configuration experience by supporting users in configuring products according to their individual requirements. We discussed methods for the recommendation of feature values and the personalized ranking of configurations. We see our contribution as an important step on the way towards more intelligent configuration user interfaces that help to improve the quality of applications in different dimensions such as prediction accuracy or overall satisfaction with the configuration environment.

References Bagley, C., Felfernig, A., Tiihonen, J., Wortley, L., Hotz, L., 2014. Benefits of configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 29–33 (Chapter 4). Barker, V., O’Connor, D., Bachant, J., Soloway, E., 1989. Expert systems for configuration at digital: XCON and beyond. Communications of the ACM 32 (3), 298–318. Bettman, J., Luce, M., Payne, J., 1998. Constructive consumer choice processes. Journal of Consumer Research 25 (3), 187–217. Cöster, C., Gustavsson, A., Olsson, R., Rudström, A., 2002. Enhancing web-based configuration with recommendations and cluster-based help. In: Francesco, R., Barry, S. (Eds.), AH’02 Workshop on Recommendation and Personalized in e-Commerce. Universidad de Málaga, Málaga, Spain, pp. 30–40. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Felfernig, A., Friedrich, G., Jannach, D., Zanker, M., 2006. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC) 11 (2), 11–34. Felfernig, A., Gula, B., Leitner, G., Maier, M., Melcher, R., Teppan, E., 2008. Persuasion in knowledge-based recommendation. In: Oinas-Kukkonen, H., Hasle, P.F.V., Harjumaa, M., Segerståhl, K., Øhrstrøm, P. (Eds.), Persuasive Technology, 3rd International Conference (PERSUASIVE 2008). Lecture Notes in Computer Science, vol. 5033. Springer, Oulu, Finland, pp. 71–82. Felfernig, A., Schubert, M., Friedrich, G., Mandl, M., Mairitsch, M., Teppan, E., 2009. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09). Pasadena, CA, USA, pp. 791–796.

178

CHAPTER 13 Personalized Configuration

Felfernig, A., Mandl, M., Tiihonen, J., Schubert, M., Leitner, G., 2010. Personalized user interfaces for product configuration. In: Rich, C., Yang, Q., Cavazza, M., Zhou, M.X. (Eds.), 15th ACM International Conference on Intelligent User Interfaces (IUI’2010). ACM, Hong Kong, China, pp. 317–320. Felfernig, A., Schippel, S., Leitner, G., Reinfrank, F., Isak, K., Mandl, M., Blazek, P., Ninaus, G., 2013a. Automated repair of scoring rules in constraint-based recommender systems. AI Communications 26 (2), 15–27. Felfernig, A., Schubert, M., Reiterer, S., 2013b. Personalized diagnosis for over-constrained problems. In: 23rd International Conference on Artificial Intelligence. Peking, China, pp. 1990–1996. Felfernig, A., Reiterer, S., Reinfrank, F., Ninaus, G., Jeran, M., 2014. Conflict detection and diagnosis in configuration. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 73–87 (Chapter 7). Geneste, L., Ruet, M., 2001. Experience-based configuration. In: 17th International Conference on Artificial Intelligence, Workshop on Configuration. Seattle, WA, pp. 45–49. Heiskala, M., Paloheimo, K.-S., Tiihonen, J., 2007. Mass customization with configurable products and configurators: a review of benefits and challenges. In: Mass customization information systems in business, 1st ed. IGI Global, pp. 1–32 (Chapter 1). Hotz, L., Felfernig, A., Stumptner, M., Ryabokon, A., Bagley, C., Wolter, K., 2014. Configuration knowledge representation and reasoning. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 41–72 (Chapter 6). Huber, J., Payne, W., Puto, C., 1982. Adding asymmetrically dominated alternatives: violations of regularity and the similarity hypothesis. Journal of Consumer Research 9 (1), 90–98. Huffman, C., Kahn, B., 1998. Variety for sale: mass customization or mass confusion. Journal of Retailing 74 (4), 491–513. Jacoby, J., Speller, D., Kohn, C., 1974. Brand choice behavior as a function of information load. Journal of Marketing Research 11 (1), 63–69. Kivetz, R., Simonson, I., 2000. The effects of incomplete information on consumer choice. Journal of Marketing Research 37 (4), 427–448. Kolodner, J., 1993. Case-Based Reasoning. Morgan Kaufmann, Waltham, MA. Mackworth, A., 1977. Consistency in networks of relations. Artificial Intelligence 8 (1), 99–118. Malhotra, N.K., 1982. Information load and consumer decision making. Journal of Consumer Research 8 (4), 419–430. Mandl, M., Felfernig, A., Teppan, E., 2014. Consumer decision making and configuration systems. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 181–190 (Chapter 14). McSherry, D., 2003. Similarity and compromise. In: Ashley, K.D., Bridge, D. (Eds.), 5th International Conference on Case-Based Reasoning (ICCBR-03). Springer Verlag, Trondheim, Norway, pp. 291–305. McSherry, D., Sep. 2004. Maximally successful relaxations of unsuccessful queries. In: Lorraine, M., Brian, C. (Eds.), 15th Irish Conference on Artificial Intelligence and Cognitive Science (AICS-04). UCD, Galway, Ireland, pp. 127–136. McSherry, D., August 2005. Incremental nearest neighbour with default preferences. In: Norman, C. (Ed.), 16th Irish Conference on Artificial Intelligence and Cognitive Science (AICS-05). University of Ulster, Portstewart, Northern Ireland, pp. 9–18. Nica, I., Wotawa, F., Ochenbauer, R., Schober, C., Hofbauer, H., Boltek, S., 2014. Kapsch: reconfiguration of mobile phone networks. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 229–240 (Chapter 19).

References

179

O’Sullivan, B., Papadopoulos, A., Faltings, B., Pu, P., 2007. Representative explanations for over-constrained problems. In: Holte, R.C., Howe, A.E. (Eds.), Twenty-Second AAAI Conference on Artificial Intelligence (AAAI-07). AAAI Press, Vancouver, Canada, pp. 323–328. Piller, F.T., Blazek, P., 2014. Core capabilities of sustainable mass customization. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 107–120 (Chapter 9). Pine, B.J., 1993. Mass customization: The New Frontier in Business Competition. Harvard Business School Press. Stumptner, M., 1997. An overview of knowledge-based configuration. AI Communications 10 (2), 111–126. Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406. Tsang, E., 1993. Foundations of Constraint Satisfaction. Academic Press, London, San Diego, New York. Tseng, M., Jiao, J., 2001. Mass customization. In: Salvendy, G. (Ed.), Handbook of Industrial Engineering, 3rd ed. Wiley, New York, pp. 684–709 (Chapter 25). Wilson, D., Martinez, T., 1997. Improved heterogenous distance functions. Journal of Artificial Intelligence Research 6, 1–34. Winterfeldt, D., Edwards, W., 1986. Decision Analysis and Behavioral Research. Cambridge University Press, Cambridge.

This page is intentionally left blank

CHAPTER

Consumer Decision-Making and Configuration Systems

14

Monika Mandl* , Alexander Felfernig* , and Erich Teppan† † Alpen

* Graz University of Technology, Graz, Austria Adria Universität Klagenfurt, Klagenfurt, Austria

Abstract: Configuring complex products and services can be challenging for users. Due to the complexity of the underlying decision tasks, decisions are often influenced by different types of decision biases. Such biases can move users toward unintended results and are often the major reason for suboptimal decisions. In this chapter, we provide an overview of different types of decision biases, which can be of relevance for tasks related to configuration processes.

14.1 Introduction A couple of theories that explain the existence of different types of decision biases in consumer decision making can be found in psychological literature. Consumers are influenced by the way in which the information is presented and, as a consequence, use different decision-making strategies (see, e.g., Asch, 1949; Bettman et al., 1991; Tversky and Kahneman, 1981). For example, the results of a study conducted by Asch illustrate the importance of an item’s position in a list. The experiment demonstrated that when presenting adjectives describing a person in sequence, the same words could result in very different ratings of that person depending on the order in which the words were presented. This effect is known as primacy effect which can also be expected in different orderings of product descriptions (Felfernig et al., 2007). The results of the research of Mandel and Johnson (1998) indicate that web page design can have an impact on users’ perceived importance of product attributes and therefore on the final product choice— this is known as priming effect. In their study they confronted the participants with a user interface that supported the selection of furniture items. One version of the interface had a “money-related” background (coins were shown to the user), the other interface had a fleecy cloud background. When using the first version of the interface, users chose furniture items that were significantly less expensive. If the user’s opinion is biased in the preference construction process,1 this can lead to imprecise and erroneous preference information, and as a consequence, to less accurate product predictions. Another problem is that decision biases can lead to unscrupulous business practices since online retailers could exploit these biases to increase sales. This motivates the investigation of decision biases in the context 1 In a purchasing process, users typically do not know their preferences beforehand but construct their preferences when interacting with the online selling application (e.g., with a configurator; Bettman et al., 1998; Mandel and Johnson, 1998). Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00014-1 © 2014 Elsevier Inc. All rights reserved.

181

182

CHAPTER 14 Consumer Decision-Making and Configuration Systems

Table 14.1 Selected decision psychological theories related to decision biases. Theory

Explanation

Decoy effects

Inferior products added to a result set can significantly change the outcome of the decision process (Huber et al., 1982; Simonson and Tversky, 1992; Teppan and Felfernig, 2009b, 2012). Primacy/recency Information units at the beginning and the end of a list are analyzed and recalled significantly more often than those in the middle of a list; this has an impact on a user’s selection behavior (Felfernig et al., 2007; Murphy et al., 2006). Defaults Preselected decision alternatives have the potential to significantly change the outcome of a decision process (Mandl et al., 2011; Samuelson and Zeckhauser, 1988).

of product configuration. An important research area is the development of user interfaces that either counteract these biases or exploit the effects in a way that improves user experience (Teppan and Felfernig, 2012). The major contributions of this chapter are the following. We provide an overview of potential decision biases that can occur when interacting with a configuration system. With this overview we raise the awareness of the existence of decision biases and also encourage researchers from the areas of computer science and decision psychology to focus on related research questions. In the remainder of this chapter we will summarize selected theories from decision psychology with respect to their potential impact on preference construction and product (configuration) choice processes—an overview of these theories is given in Table 14.1. First, we will present decision effects that are related to the inclusion of low-quality items/configurations (decoy items) to result sets (Section 14.2).2 In Section 14.3 we discuss the impact of the ordering of items on item selection (primacy/recency effects). Finally, we investigate decision effects that are related to the presentation of defaults (Section 14.4; see also Tiihonen et al., 20143 ). This chapter is concluded with Section 14.5.

14.2 Decoy Effects 14.2.1 Overview Decoy items can be, for example, (partial) configurations that are inferior to others in a given set. In this context, the inferiority or superiority of products, respectively, is measured by simply comparing the underlying properties.4 For example, in Table 14.3 computer RAM I dominates computer D in the dimensions price and capacity since it has both a lower price and a higher memory capacity. The inclusion of decoy products (configurations) can significantly influence the outcome of the decision process. This effect is known as the decoy effect (Huber et al., 1982; Simonson and Tversky, 1992; Teppan and Felfernig, 2009b) and is of special relevance in the result presentation phase within a configuration process. 2 In

the configuration context, this is a set of alternative (partial) configurations shown to the user. 13. 4 Note that we use the computer product domain in the following examples. 3 Chapter

14.2 Decoy Effects

183

FIGURE 14.1 Different types of decoy items discussed in this chapter.

In the following subsections we will discuss different types of decoy effects (compromise, asymmetric dominance, and attraction) and explain how these effects can influence the outcome of a decision process. Figure 14.1 provides an overview of the different types of decoy effects discussed in this chapter. Note that the computers RAM I and RAM II appear on the Pareto line, which means that they have a comparable utility (computer RAM I has a higher capacity whereas RAM II has a lower price). Compromise Effects. Compromise effects denote one specific archetype of decoy effects (see Table 14.2). Simonson and Tversky (1992) demonstrated that adding an extreme alternative to a choice set will result in people favoring the “middle” choice where attribute values are positioned between the values of the other alternatives. For example, the attractiveness of computer RAM I compared to computer RAM II can be increased by adding computer D to the set of alternatives (see Table 14.2). Since RAM I has a significantly lower price and only a marginally lower capacity compared to D, computer RAM I is established as a compromise between the alternatives RAM II and D. Asymmetric Dominance Effects. The second archetype of decoy effect is called asymmetric dominance (depicted in Table 14.3). In this scenario, computer RAM I dominates computer D in both attributes (price and capacity), whereas computer RAM II dominates D in only one dimension (the price). Therefore, the addition of computer D to the set can increase the share of computer RAM I. The underlying effect is that users interpret RAM I of being the better choice since it outperforms—in contrast to RAM II—D in both dimensions.

184

CHAPTER 14 Consumer Decision-Making and Configuration Systems

Table 14.2 Compromise effect: RAM I is a compromise between RAM II and D. Product (Computer)

RAM I

RAM II

Price [0..100] Capacity [0..10 GB]

65 8.5

25 4.5

D 80 9

Table 14.3 Asymmetric dominance effect: RAM I dominates D in both dimensions (capacity and price). Product (Computer)

RAM I

RAM II

D

Price [0..100] Capacity [0..10 GB]

65 8.5

25 4.5

75 8

Table 14.4 Attraction effect: RAM I has a marginally higher price but a lower capacity. Product (Computer)

RAM I

RAM II

D

Price [0.100] Capacity [0..10 GB]

65 8.5

25 4.5

60 6

Attraction Effects. The third archetype of decoy effects is called attraction effect. In this scenario, decoy products are positioned between the target and the competitor product (see Table 14.4). In this context, computer RAM I appears to be only a little bit more expensive and simultaneously has a significantly higher capacity compared to computer D, and therefore the inclusion of computer D can increase the attractiveness of computer RAM I.

14.2.2 Relevance of Decoy Effects in Product Configuration Scenarios If decoy configurations are added to a result set, this can change the selection probability for configurations that were included in the original result set. The existence of decoy effects has been shown in a number of empirical studies in application domains such as financial services, e-tourism, and even software agents (see, e.g., Teppan and Felfernig, 2009a; Teppan et al., 2011, 2010). The major possibilities of exploiting decoy effects in product configuration scenarios are the following: •

Increased selection probability for target items: As already mentioned, adding additional inferior items to a result set can cause an increased share of target items (in our example denoted as computer RAM I). This scenario definitely has ethical aspects to be dealt with since companies can potentially try to apply decoy effects for selling products that are suboptimal for the customer.

14.3 Serial Position Effects

185

FIGURE 14.2 Serial position effect (Ebbinghaus et al., 1885). Items at the beginning and at the end of a list are more accurately recalled than those items positioned in the middle of a list.

•

Increased decision confidence: Besides an increase of the share of the target product, decoy effects can be exploited for increasing the decision confidence of a user. In this context, decoy effects can be exploited for resolving cognitive dilemmas that occur when a user is unsure about which alternative to choose from a given set of nearly equivalent alternatives.

14.3 Serial Position Effects 14.3.1 Overview In 1946 Solomon Asch conducted an experiment on formations of personality impression that aimed at analyzing the importance of an item’s list position (Asch, 1949). The results of this study showed that presenting adjectives describing a person in sequence, the same words could result in very different ratings of that person depending on the order in which the words were presented. A person described as intelligent, industrious, impulsive, critical, stubborn, envious was rated more positive by the participants than a person described as envious, stubborn, critical, impulsive, industrious, intelligent. This phenomenon is known as primacy effect and can be explained by a memory advantage that early items in a list have (Crowder, 1976; see Figure 14.2). Murphy et al. (2006) demonstrated serial position effects in an online environment where they manipulated the serial position of links (to the restaurant’s offerings) on the website of a popular restaurant. In this experiment, visitors tended to click the link on first position most frequently, but there was also an increased tendency to click on the links at the end of the list—this is known as recency effect. The results go along with the findings of Ebbinghaus et al. (1885), who first documented serial position effects, the relationship between recall probability of an item and its position in a list (see Figure 14.2). Felfernig et al. (2007) investigated serial position effects in knowledge-based recommendation scenarios. They conducted a study where participants were asked to choose a tent out of a set of tents that he/she most likely would buy. The results of this study showed significant changes in the product selection behavior triggered by the ordering of the position of product attributes used to describe the

186

CHAPTER 14 Consumer Decision-Making and Configuration Systems

Table 14.5 Scoring rules for product attribute price. Price

Economy

Quality

≤ 25 > 25, ≤ 50 > 50, ≤ 75 > 75, ≤ 100

10 6 4 2

3 5 7 10

Table 14.6 Scoring rules for product attribute capacity. Capacity

Economy

Quality

≤3

10 6 4

4 7 10

> 3, ≤ 6 > 6, ≤ 10

tents (Felfernig et al., 2007). Finally, the existence of serial position effects due to different orderings of choice alternatives (options) is shown in Li and Epley (2009).

14.3.2 Relevance of Serial Position Effects in Product Configuration Scenarios Product configuration systems have been recognized as ideal tools to assist customers in configuring complex products according to their individual preferences (Blecker et al., 2004; Yang et al., 2005). In this context, serial position effects play an important role in the ordering choice alternatives; configuration systems must be aware of the fact that different rankings can trigger different selection behavior, and as well can increase or reduce a user’s decision-making effort. Murphy et al. (2006) suggest to place the most important item on the first position, and to place another important item on the last position of a list (the process should be continued with the order of importance). Felfernig et al. (2008) introduced an approach to calculate personalized item rankings, and to take into account primacy/recency effects in the presentation of result sets in the context of a recommendation scenario. They apply the concepts of Multi-Attribute Utility Theory (MAUT; Winterfeldt and Edwards, 1986) and derive the importance of interest dimensions from customer requirements (see also Felfernig et al., 2006, 2013). A simple example of the concepts presented in Felfernig et al. (2008) is the following. Let us assume that economy and quality have been defined as interest dimensions for the computer product domain introduced in Section 14.2. In Tables 14.5 and 14.6 example scoring rules are defined, which describe the relationships between the computer attributes (price and capacity) and the corresponding interest dimensions (economy and quality). For example, Table 14.5 shows that an expensive computer has a low perceived value for interest dimension economy, and a high perceived value for interest dimension quality. Table 14.6 shows that a computer with a low capacity has a high valence in interest domain economy, and a low valence in interest dimension quality.

14.4 Status Quo Effect

187

Table 14.7 Overall utilities of computers in Table 14.4. Computer

Economy

Quality

Overall utility

I II D

4+4=8 10 + 6 = 16 4 + 6 = 10

7 + 10 = 17 3 + 7 = 10 7 + 7 = 14

8 ∗ 0.5 + 17 ∗ 0.5 = 10.5 16 ∗ 0.5 + 10 ∗ 0.5 = 9.0 10 ∗ 0.5 + 14 ∗ 0.5 = 9.5

A personalized product ranking can be calculated on the basis of Formula 14.1. In this formula, contribution (r,i) defines the contribution of product r to the interest dimension i, and interest (i) shows the degree to which a specific customer is interested in dimension i. productutility(r ) =

n 

contribution(r , i) ∗ interest(i)

(14.1)

i=1

Let’s assume a concrete customer (customer A) with an equal interest in the dimension quality (importance of 0.5) and the dimension economy (importance of 0.5). Applying the scoring rules of Tables 14.5 and 14.6 to the computers of Table 14.4 results in the product (configuration) ranking shown in Table 14.7. This customer-specific ranking of products can now be used to identify an ordering of computers that takes into account primacy/recency effects; one can expect that on the basis of such an ordering, the probability of unreasonable choice can be reduced.

14.4 Status Quo Effect 14.4.1 Overview Research in human decision-making has revealed the fact that people have a strong tendency to keep the status quo when choosing among alternatives (see, e.g., Kahneman et al., 1991; Samuelson and Zeckhauser, 1988). This effect is known as status quo bias. A consequence of this is that proposed decisions (e.g., decisions proposed by experts or by the configurator application) that represent the status quo are accepted by the user. Defaults (see, e.g., Tiihonen et al., 20145 ) can lead to such a status quo bias. The results of the research of Samuelson and Zeckhauser (1988) implied that an alternative was significantly more often chosen when it was designated as the status quo, and that the status quo effect increases with the number of alternatives. Kahneman et al. (1991) argue that the status quo bias can be explained by a notion of loss aversion, since the status quo serves as a neutral reference point, and users evaluate options in terms of gains and losses relative to the reference point. Since individuals tend to regard losses as more important than gains in decision-making under risk (i.e., alternatives with uncertain outcomes; Kahneman and Tversky, 1979) the possible disadvantages outweigh the advantages. Cosley et al. (2003) showed that presenting item ratings in collaborative filtering recommenders (Konstan et al., 1997) has an impact on the rating behavior of a user. For example, ratings were higher in situations where inflated predictions were presented to the user. 5 Chapter

13.

188

CHAPTER 14 Consumer Decision-Making and Configuration Systems

14.4.2 Relevance of the Status Quo Effect in Product Configuration Scenarios Product configuration systems are increasingly being used by manufacturing companies to assist customers in specifying their requirements, and to find a product (configuration) that matches their preferences. A side effect of the high diversity of products offered by a configurator is that the complexity of the alternatives may outstrip a user’s capability to explore them and make a buying decision. Since humans have limited processing capacity, confronting consumers with too much information can lead to an information overload and therefore can result in decreased quality of decision performance (Jacoby et al., 1974). Huffman and Kahn (1998) state that “the key to customer satisfaction with the entire shopping interaction is to ensure that the customer is equipped to handle the variety.” A possibility to support users in the specification of their requirements is to provide defaults (Falkner et al., 2011; Tiihonen and Felfernig, 2010). Defaults in configuration systems can be defined as preselected options used to express personalized feature recommendations. For example, if the user wants to play computer games, the recommended computer should have a high performance. Thus defaults are a means to help the user identify meaningful alternatives that are compatible with their current preferences. A major risk of defaults is that they could be exploited for misleading users and making them choose options that are not needed to fulfill their requirements. Ritov and Baron (1992) suggest counteracting the status quo bias by presenting the options in such a way that keeping as well as changing the status quo needs user input. They argue that “when both keeping and changing the status quo require action, people will be less inclined to err by favoring the status quo when it is worse.”

14.5 Conclusion In this chapter we have presented a selected set of decision-psychological phenomena that have impacts on the development of decision support systems such as product configurators. A number of related empirical studies clearly show the importance of taking into account such theories when implementing software systems. For more information on aspects of consumer decision-making in online purchasing scenarios refer to Häubl and Trifts (2000) and Mandl et al. (2010).

References Asch, S., 1949. Forming impressions of personality. Journal of Abnormal and Social Psychology 41 (3), 258–290. Bettman, J.R., Johnson, E.J., Payne, J.W., 1991. Consumer decision making. In: Robertson, T.S., Kassarjian, H.H. (Eds.), Handbook of Consumer Behavior. Prentice Hall, NJ, pp. 50–84 (Chapter 2). Bettman, J., Luce, M., Payne, J., 1998. Constructive consumer choice processes. Journal of Consumer Research 25 (3), 187–217. Blecker, T., Abdelkafi, N., Kreuter, G., Friedrich, G., 2004. Product configuration systems: state of the art, conceptualization and extensions. In: Proceedings of the Eight Maghrebian Conference on Software Engineering and Artificial Intelligence (MCSEAI), Sousse, Tunisia, pp. 25–36. Cosley, D., Lam, S., Albert, I., Konstan, J., Riedl, J., 2003. Is seeing believing? How recommender system interfaces affect users opinions. In: CHI 2003 Conference on Human Factors in Computing Systems. ACM, NY, Ft. Lauderdale, FL, pp. 585–592.

References

189

Crowder, R., 1976. Principles of learning and memory. In: The Experimental Psychology Series. Lawrence Erlbaum Associates, Hillsdale, NJ. Ebbinghaus, H., Ruger, H.A., Clara, E.B., 1885. Memory: a contribution to experimental psychology. In: The Experimental Psychology Series. Teachers College, Columbia University, NY. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Felfernig, A., Friedrich, G., Jannach, D., Zanker, M., 2006. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC) 11 (2), 11–34. Felfernig, A., Friedrich, G., Gula, B., Hitz, M., Kruggel, T., Melcher, R., Riepan, D., Strauss, S., Teppan, E., Vitouch, O., 2007. Persuasive recommendation: exploring serial position effects in knowledge-based recommender systems. In: De Kort, Y., IJsselsteijn, W., Midden, C., Eggen, B., Fogg, B.J. (Eds.), Second International Conference of Persuasive Technology (Persuasive 2007). Lecture Notes in Computer Science, vol. 4744. Springer, Palo Alto, CA, pp. 283–294. Felfernig, A., Gula, B., Leitner, G., Maier, M., Melcher, R., Teppan, E., 2008. Persuasion in knowledge-based recommendation. In: Oinas-Kukkonen, H., Hasle, P.F.V., Harjumaa, M., Segerståhl, K., Øhrstrøm, P. (Eds.), Persuasive Technology, Third International Conference (PERSUASIVE 2008). Lecture Notes in Computer Science, vol. 5033. Springer, Oulu, Finland, pp. 71–82. Felfernig, A., Schippel, S., Leitner, G., Reinfrank, F., Isak, K., Mandl, M., Blazek, P., Ninaus, G., 2013. Automated repair of scoring rules in constraint-based recommender systems. AI Communications 26 (2), 15–27. Häubl, G., Trifts, V., 2000. Consumer decision making in online shopping environments: the effects of interactive decision aids. Marketing Science 19 (1), 4–21. Huber, J., Payne, W., Puto, C., 1982. Adding asymmetrically dominated alternatives: violations of regularity and the similarity hypothesis. Journal of Consumer Research 9 (1), 90–98. Huffman, C., Kahn, B., 1998. Variety for sale: mass customization or mass confusion. Journal of Retailing 74 (4), 491–513. Jacoby, J., Speller, D., Kohn, C., 1974. Brand choice behavior as a function of information load. Journal of Marketing Research 11 (1), 63–69. Kahneman, D., Tversky, A., 1979. Prospect theory: an analysis of decision under risk. Econometrica 47 (2), 263–291. Kahneman, D., Knetsch, J.L., Thaler, R.H., 1991. Anomalies: the endowment effect, loss aversion, and status quo bias. Journal of Economic Perspectives 5 (1), 193–206. Konstan, J., Miller, B., Maltz, D., Herlocker, J., Gordon, L., Riedl, J., 1997. Grouplens: applying collaborative filtering to usenet news full text. Communications of the ACM 40 (3), 77–87. Li, Y., Epley, N., 2009. When the best appears to be saved for last: serial position effects on choice. Journal of Behavioral Decision Making 22 (4), 378–389. Mandel, N., Johnson, E., 1998. Constructing Preferences Online: Can Web Pages Change What You Want? Marketing Department. The Wharton School, University of Pennsylvania, Philadelphia, PA. Mandl, M., Felfernig, A., Teppan, E., Schubert, M., 2010. Consumer decision making in knowledge-based recommendation. Journal of Intelligent Information Systems (JIIS) 37 (1), 1–22. Mandl, M., Felfernig, A., Tiihonen, J., Isak, K., 2011. Status quo bias in configuration systems. In: 24th International Conference on Industrial, Engineering and Other Applications of Applied Intelligent Systems (IEA/AIE 2011). Lecture Notes in Computer Science, vol. 6703. Springer, Syracuse, NY, pp. 105–114. Murphy, J., Hofacker, C.F., Mizerski, R., 2006. Primacy and recency effects on clicking behavior. Journal of Computer-Mediated Communication 11 (2), 522–535. Ritov, I., Baron, J., 1992. Status-quo and omission biases. Journal of Risk and Uncertainty 5 (1), 49–61.

190

CHAPTER 14 Consumer Decision-Making and Configuration Systems

Samuelson, W., Zeckhauser, R., 1988. Status quo bias in decision making. Journal of Risk and Uncertainty 1 (1), 7–59. Simonson, I., Tversky, A., 1992. Choice in context: tradeoff contrast and extremeness aversion. Journal of Marketing Research 29 (3), 281–295. Teppan, E., Felfernig, A., 2009a. The asymmetric dominance effect and its role in e-tourism recommender applications. In: Ninth Internationale Tagung Wirtschaftsinformatik (WI’2009) – Business Services: Konzepte, Technologien, Anwendungen (In German), vol. 2, Vienna, Austria, pp. 791–800 (in German: Der Asymmetrische Dominanzeffekt und seine Bedeutung für E-Tourismus-Plattformen). Teppan, E.C., Felfernig, A., 2009b. Calculating decoy items in utility-based recommendation. In: 22nd International Conference on Industrial, Engineering and Other Applications of Applied Intelligent Systems (IEA/AIE 2009), Tainan, Taiwan. Lecture Notes in Computer Science, vol. 5579, pp. 183–192. Teppan, E., Felfernig, A., 2012. Minimization of product utility estimation errors in recommender result set evaluations. Web Intelligence and Agent Systems 10 (4), 385–395. Teppan, E., Friedrich, G., Felfernig, A., 2010. Impacts of decoy effects on the decision making ability. In: 12th IEEE Conference on E-Commerce and Enterprise Computing (CEC2010). IEEE, Shanghai, China, pp. 112–119. Teppan, E., Felfernig, A., Isak, K., 2011. Decoy effects in financial service E-sales systems. In: RecSys’11 Workshop on Human Decision Making in Recommender Systems (Decisions@RecSys’11), Chicago, IL, pp. 1–8. Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406. Tiihonen, J., Felfernig, A., Mandl, M., 2014. Personalized configuration. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 167–179 (Chapter 13). Tversky, A., Kahneman, D., 1981. The framing of decisions and the psychology of choice. Science 211 (4481), 453–458. Winterfeldt, D., Edwards, W., 1986. Decision Analysis and Behavioral Research. Cambridge University Press, Cambridge. Yang, Y., Zhang, X., Liu, F., Xie, Q., 2005. An internet-based product customization system for CIM. Robotics and Computer-Integrated Manufacturing 21 (2), 109–118.

CHAPTER

Configuration-Related Research Challenges

15

Alexander Felfernig* , Lothar Hotz† , Claire Bagley‡ and Juha Tiihonen§ † HITeC

* Graz University of Technology, Graz, Austria e.V., University of Hamburg, Hamburg, Germany ‡ Oracle Corporation, Burlington, MA, USA § Aalto University, Aalto, Finland

Abstract: In this part on advanced topics in configuration, we took a look at the issues of configuration knowledge engineering (testing and debugging and redundancy detection) and intelligent configurator user interfaces (personalized configuration and consumer decision-making). To stimulate further configuration-related research, we conclude this part with a discussion of issues for future research.

Personalized Configuration The quantity and complexity of options presented to a user often outstripts his/her capability to identify appropriate solutions (configurations; Ardissono et al., 2003; Cöster et al., 2002; Falkner et al., 2011; Felfernig et al., 2012a; Huffman and Kahn, 1998; Tiihonen and Felfernig, 2010). Users are often not able to find the features they would like to specify, they are unsure about their preferences regarding complex technical properties, and they do not know in which way to change their requirements if no solution can be found. Also due to the size and complexity of the underlying product assortment sales representatives tend to sell products they already know and thus are overlooking configurations that would better fit the needs of the user (Tiihonen and Felfernig, 2010). A major challenge in this context is also the fact that users do not know their preferences beforehand but rather construct their preferences within the scope of the configuration process (Bettman et al., 1998; Häubl and Murray, 2003). These challenges have to be tackled in terms of a new generation of personalized configuration technologies that proactively support the user and guide him/her through the configuration process in an intuitive fashion. Configuration and Feature Models Feature models (FMs; Asikainen et al., 2003, 2004, 2006; Benavides et al., 2010; Czarnecki et al., 2004, 2005; Kang et al., 1990) are a means to represent an assortment of feature configurations on a graphical level (see also Hotz et al., 20141 and Hotz and Wolter, 20142 ). In the feature models research community, analysis operations for feature models are a thriving research area that attracted attention in the last years. For example, Benavides et al. (2010) report more than 30 analysis operations for feature models that help to assure well-formedness of the underlying models. These operations developed in the feature model community are not well known in the configuration research community. Consequently, an issue for future research is to investigate existing FM analysis operations and to adapt and extend these operations in order to be useful in configuration settings 1 Chapter

2 Chapter

6. 10.

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00015-3 © 2014 Elsevier Inc. All rights reserved.

191

192

CHAPTER 15 Configuration-Related Research Challenges

(Benavides et al., 2013). To generalize this aspect, the analysis of potential synergies between these two research areas in a systematic fashion is a major issue for future research. An in-depth discussion of related research questions can be found, for example, in Benavides et al. (2013) and Hubaux et al. (2012). Community-based Configuration Typically, configuration is assumed to be a process where one user interacts with the configuration system with the goal to identify a solution (configuration). A major research question in this context is how to best support configuration processes that include groups of users (Felfernig et al., 2012b; Jameson, 2004). Examples of such settings are the configuration of holiday trips, software release plans, and (also) car configuration. In these scenarios, users often cooperatively design their solutions, which requires additional configuration functionalities such as feature (value) recommendation for groups of users, diagnosis and repair recommendation for groups of users, configuration ranking for groups of users, and so on. From these questions we can derive the general research question that should be answered: In which way do we have to adapt (extend) existing user interfaces, algorithms, and configuration processes to be able to support groups of users? Standardized Configuration Knowledge Representations Still a major research issue is the development of a configuration lingua franca. Such a language would help to make configuration knowledge interchangeable between different configuration environments and thus also to better protect corporate assets with regard to technological changes. Furthermore, such a knowledge representation language would help to make the empirical evaluation of new algorithmic developments easier since less effort has to be spent translating existing configuration knowledge bases into the dialect of a specific configuration environment (under the assumption that each environment is able to import/export standard representations). Research dedicated to the development of such a standardized knowledge representation focused on common ontologies (Soininen et al., 1998), UML (Felfernig, 2007; Felfernig et al., 2000), and description logics based representations (see, e.g., Felfernig et al., 2003). The major issue for future research is the development of a common representation language that (1) takes into account all relevant aspects of configuration knowledge (e.g., ports, composite and shared part of hierarchies) and (2) also provides the semantics that allows for efficient solution search. Research in answer set programming based configuration shows promising results that will pave the way for achieving the mentioned goals (Aschinger et al., 2012; Friedrich et al., 2011; Simons et al., 2002; Tiihonen et al., 2003, 2013). Intelligent User Interfaces for Configuration Knowledge Acquisition The engineering of complex configuration knowledge bases is typically a cooperative process where different stakeholders such as product designers, marketing and sales experts, and knowledge engineers are engaged. Each stakeholder is familiar with only specific aspects of the product domain and even on the technical level there are different experts with different knowledge regarding the underlying product. Furthermore, stakeholders often have conflicting interests regarding the features that should be supported by a configurable product. Major questions to be answered in this context are the following: which components should be part of the knowledge base (i.e., offered to the customer)? Which constraints should be part of the knowledge base? How to achieve consensus among the different stakeholders? Another issue in this context is the accessibility of a knowledge base: highly experienced knowledge engineers have a different navigation behavior in the knowledge base compared to less experienced engineering personnel. A major research issue in this context is the development of intelligent techniques that support easy understanding and handling of configuration knowledge bases (Felfernig et al., 2013). Questions to be answered in this context are the following: Which constraints should additionally be inspected after having already inspected a specific sequence of constraints? Which parts of a knowledge base should not be shown to the engineer

References

193

in certain maintenance contexts? How do we refactor ill-formed knowledge bases? In this context, we have to develop deep knowledge related to the cognitive complexity of different constraint structures and types. Initial research results related to this topic have been reported in Felfernig et al. (2010a). Intelligent Testing and Debugging Besides the determination of minimal sets of user requirements that are inconsistent with regard to a configuration knowledge base, the concepts of model-based diagnosis (MBD; Reiter, 1987) can as well be applied to the testing and debugging of configuration knowledge bases (see Felfernig et al., 2004). If a configuration knowledge base is inconsistent with some (or all) of the test cases of a test suite, we are interested in minimal explanations in terms of minimal sets of constraints in the knowledge base that have to be deleted or adapted to be able to restore the consistency of the knowledge base with regard to the test suite. Research questions to be answered in the context of knowledge base testing and debugging are the following: How do we automatically generate test suites? How can test case generation techniques from software engineering be applied or extended in knowledge-based configuration scenarios? How can we personalize the determination of diagnoses, for example, on the basis of complexity metrics that provide an indicator of the quality of certain parts of a knowledge base? How can we increase the efficiency of debugging algorithms? Unobtrusive Preference Elicitation Similar to recommender systems, the quality of user preference estimation is a major factor for successfully determining configurations that are of interest for the user (under the assumption that personalization technologies are already integrated in the configuration environment). In many configurators (and also recommender applications) preference elicitation is based on concepts such as directly asking the user or inferring preferences from the interaction logs of previous user interactions (see, e.g., Felfernig et al., 2009, 2010b). Alternative ways to derive preferences from user interactions are, for example, the (online) interpretation of eye-tracking data or the derivation of requirements and preferences on the basis of voice processing. These are issues for future research. Processes for Intelligent Systems Development The widespread application of knowledge-based technologies triggers the demand of methodologies that support application development in a structured fashion. A related research question is to which extent standard software engineering methods are applicable or whether agile methods provide a better methodological support. A discussion of the application of agile methods in the context of knowledge-based systems development can be found, for example, in Knublauch and Rose (2003).

References Ardissono, L., Felfernig, A., Friedrich, G., Goy, A., Jannach, D., Petrone, G., Schäfer, R., Zanker, M., 2003. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine 24 (3), 93–108. Aschinger, M., Drescher, C., Vollmer, H., 2012. LoCo – a logic for configuration problems. In: 20th European Conference on Artificial Intelligence (ECAI2012). IOS Press, Montpellier, France, pp. 73–78. Asikainen, T., Soininen, T., Männistö, T., 2003. Towards managing variability using software product family architecture models and product configurators. In: Proceedings of the Software Variability Management Workshop, Groningen, The Netherlands, pp. 84–93. Asikainen, T., Männistö, T., Soininen, T., August 2004. Representing feature models of software product families using a configuration ontology. In: 16th European Conference on Artificial Intelligence (ECAI-2004), Configuration Workshop, Valencia, Spain.

194

CHAPTER 15 Configuration-Related Research Challenges

Asikainen, T., Männistö, T., Soininen, T., 2006. A unified conceptual foundation for feature modeling. In: 10th International Software Product Line Conference (SPLC 2006). IEEE Computer Society, Baltimore, MD, pp. 31–40. Benavides, D., Segura, S., Ruiz-Cortés, A., 2010. Automated analysis of feature models 20 years later: a literature review. Information Systems 35 (6), 615–636. Benavides, D., Felfernig, A., Galindo, J., Reinfrank, F., 2013. Automated analysis in feature modelling and product configuration. In: 13th International Conference on Software Reuse. Lecture Notes in Computer Science, vol. 7925. Springer, Pisa, Italy, pp. 160–175. Bettman, J., Luce, M., Payne, J., 1998. Constructive consumer choice processes. Journal of Consumer Research 25 (3), 187–217. Cöster, C., Gustavsson, A., Olsson, R., Rudström, A., 2002. Enhancing web-based configuration with recommendations and cluster-based help. In: Francesco, R., Barry, S. (Eds.), AH’02 Workshop on Recommendation and Personalized in e-Commerce, Universidad de Málaga, Málaga, Spain, pp. 30–40. Czarnecki, K., Helsen, S., Eisenecker, U., 2004. Staged configuration using feature models. In: Third Software Product-Line Conference (SPLC’04), Boston, USA, pp. 266–283. Czarnecki, K., Helsen, S., Eisenecker, U., 2005. Formalizing cardinality-based feature models and their specialization. Software Process: Improvement and Practice 10 (1), 7–29. Falkner, A., Felfernig, A., Haag, A., 2011. Recommendation technologies for configurable products. AI Magazine 32 (3), 99–108. Felfernig, A., 2007. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management 54 (1), 41–56. Felfernig, A., Friedrich, G.E., Jannach, D., 2000. UML as domain specific language for the construction of knowledge-based configuration systems. International Journal of Software Engineering and Knowledge Engineering 10 (4), 449–469. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., Zanker, M., 2003. Configuration knowledge representations for semantic web applications. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 17 (1), 31–50. Felfernig, A., Friedrich, G., Jannach, D., Stumptner, M., 2004. Consistency-based diagnosis of configuration knowledge bases. Artificial Intelligence 152 (2), 213–234. Felfernig, A., Schubert, M., Friedrich, G., Mandl, M., Mairitsch, M., Teppan, E., 2009. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA, pp. 791–796. Felfernig, A., Mandl, M., Pum, A., Schubert, M., 2010a. Empirical knowledge engineering: cognitive aspects in the development of constraint-based recommenders. In: 23rd International Conference on Industrial Engineering and Other Applications of Applied Intelligent Systems (IEA/AIE 2010), Cordoba, Spain, pp. 631–640. Felfernig, A., Mandl, M., Tiihonen, J., Schubert, M., Leitner, G., 2010b. Personalized user interfaces for product configuration. In: Rich, C., Yang, Q., Cavazza, M., Zhou, M.X. (Eds.), 15th ACM International Conference on Intelligent User Interfaces (IUI’2010). ACM, Hong Kong, China, pp. 317–320. Felfernig, A., Schubert, M., Zehentner, C., 2012a. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 26 (1), 53–62. Felfernig, A., Zehentner, C., Ninaus, G., Grabner, H., Maalej, W., Pagano, D., Weninger, L., Reinfrank, F., 2012b. Group decision support for requirements negotiation. In: Advances in User Modeling. Lecture Notes in Computer Science, vol. 7138. Springer, Girona, Spain, pp. 105–116. Felfernig, A., Reiterer, S., Stettinger, M., Reinfrank, F., Jeran, M., Ninaus, G., 2013. Recommender systems for configuration knowledge engineering. Workshop on Configuration, Austria, Vienna, pp. 51–54 Friedrich, G., Ryabokon, A., Falkner, A.A., Haselböck, A., Schenner, G., Schreiner, H., 2011. (Re)configuration based on model generation. Second Workshop on Logics for Component Configuration (LoCoCo 2011), Perugia, Italy, pp. 26–35.

References

195

Häubl, G., Murray, K., 2003. Preference construction and persistence in digital marketplaces: the role of electronic recommendation agents. Journal of Consumer Psychology 13 (1–2), 75–91. Hotz, L., Wolter, K., 2014. Smarthome configuration model. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 121–135 (Chapter 10). Hotz, L., Felfernig, A., Stumptner, M., Ryabokon, A., Bagley, C., Wolter, K., 2014. Configuration knowledge representation and reasoning. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 41–72 (Chapter 6). Hubaux, A., Jannach, D., Drescher, C., Murta, F., Männistö, T., Czarnecki, K., Heymans, P., Nguyen, N., Zanker, M., 2012. Unifying software and product configuration: a research roadmap. In: Mayer, W., Albert, P. (Eds.), ECAI 2012 Workshop on Configuration, Montpellier, France, pp. 31–35. Huffman, C., Kahn, B., 1998. Variety for sale: mass customization or mass confusion. Journal of Retailing 74 (4), 491–513. Jameson, A., 2004. More than the sum of its members: challenges for group recommender systems. In: International Working Conference on Advanced Visual Interfaces, pp. 48–54. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S., 1990. Feature-oriented domain analysis feasibility study (FODA). Tech. Rep. CMU/SEI-90-TR-021, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA. Knublauch, H., Rose, T., 2003. Tool-supported process analysis and design for the development of multi-agent systems. In: Agent-Oriented Software Engineering III, Third International Workshop, AOSE 2002. Lecture Notes in Computer Science, vol. 2585. Springer, Bologna, Italy, pp. 186–197. Reiter, R., 1987. A theory of diagnosis from first principles. Artificial Intelligence 32 (1), 57–95. Simons, P., Niemelä, I., Soininen, T., 2002. Extending and implementing the stable model semantics. Artificial Intelligence 138 (1–2), 181–234. Soininen, T., Tiihonen, J., Männistö, T., Sulonen, R., 1998. Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM) 12 (4), 357–372. Tiihonen, J., Felfernig, A., 2010. Towards recommending configurable offerings. International Journal of Mass Customization 3 (4), 389–406. Tiihonen, J., Soininen, T., Niemelä, I., Sulonen, R., 2003. 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, p. 10 (Paper number: 1290). Tiihonen, J., Heiskala, M., Anderson, A., Soininen, T., 2013. WeCoTin – a practical logic-based sales configurator. AI Communications 26 (1), 99–131.

This page is intentionally left blank

PART

Case Studies

4

This page is intentionally left blank

CHAPTER

SIEMENS: Configuration and Reconfiguration in Industry

16

Andreas Falkner and Herwig Schreiner Siemens AG Österreich, Vienna, Austria

Abstract: Whereas the configuration of consumer products such as PCs, cars, insurances, and such is well understood and supported by commercial tools, large-scale industrial systems still raise considerable challenges concerning modeling, solving, and performance. After a short explanation of the importance of this topic to Siemens, this chapter presents the domain of railway interlocking systems as an example of such complex industrial systems and discusses detailed requirements for their configuration. It then reports on techniques used for solving those requirements at Siemens as well as on results of their application.

16.1 Introduction Siemens1 is a global company that produces a rich variety of products in its four sectors, Energy, Industry, Healthcare, and Infrastructures and Cities, from relatively small items (such as electric power supplies, gear units, etc.) to very complex items (such as power plants, gas turbines, railway interlocking systems, etc.). Many of these products are configurable, either by a Siemens engineer or sales manager who prepares a bid, or directly by a business customer who selects components or features before buying the product. Depending on the special requirements of the products and production processes, Siemens uses different configurators, some tailor-made (such as Siemens Industry Mall), some using configurators built into Siemens’ product life-cycle management tools COMOS and Teamcenter, and some based on external commercial tools (such as SAP’s Variant Configurator or Internet Pricing Configurator2 ). None of those tools was available or well suited for the task of configuring a new type of Siemens railway interlocking system developed in the 1990s. The challenge was to move from an engineer-toorder type of process (suitable for traditional relay interlockings) to a configure-to-order process in order to reduce costs for the new type of electronic interlockings. This posed the following challenges for the configuration system: • • 1 2

High variability: Many different component types and subtypes (hundreds of types, thousands of attributes), different variants for different countries Dynamic data: The number of components is not fixed but is derived only during the configuration process http://www.siemens.com. http://www.sap.com.

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00016-5 © 2014 Elsevier Inc. All rights reserved.

199

200

CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry

FIGURE 16.1 Large railway hub with shunting tracks.

• • •

•

High complexity: Network (not only tree) of component connections, complicated restrictions, consistency and completeness conditions, and optimization criteria Very large systems (tens of thousands of components) Semi-interactive usage: On the one hand, the search for a solution is to be highly automated; on the other hand, the engineers are to be allowed to edit all components and attributes directly in order to cover special requirements Long lifespan (more than 20 years): Easy maintenance of the knowledge base, repeated reconfigurations (i.e., updating or extending an existing system) are required

To a large extent, these requirements were similar to those encountered for the configuration of Siemens’ EWSD telephone switching systems. For that purpose, a tailor-made configuration system based on generative constraint satisfaction (Fleischanderl et al., 1998) was used successfully. The core of that system was reimplemented in Java (see Haselböck and Schenner, 20143 for a description of this framework) and used as a basis to build configurators for electronic railway interlockings and other railway safety systems; see Falkner et al. (2007) for a report on the relevant experience. The remainder of this chapter presents the domain of railway interlocking systems in Section 16.2 and the requirements that such complex industrial systems impose upon configuration (Section 16.3). Section 16.4 reports on techniques used for solving those requirements with the aforementioned system and Section 16.5 concludes with describing the main effects of their application.

16.2 Domain: Railway Interlocking Systems Railway interlocking systems ensure safe railway operations. They are used to monitor and control railway stations such as the one shown in Figure 16.1. Fundamental principles of railway interlockings include the following: Signals must not be operated so as to permit conflicting train movements at the 3 Chapter

22.

16.2 Domain: Railway Interlocking Systems

201

same time. Points (switches) and other field elements in a train route must be set to correct positions before a signal may allow train movements to enter that route. Electronic railway interlockings consist of thousands of components with hundreds of different types of hardware, software, and interfaces. A railway interlocking can be represented as a network of (possibly repeated) subcomponents, for example: field equipment such as signals, lamps, and cables; computer rooms with hardware racks, frames, and modules of various types and the interconnecting wiring (as shown in Figure 16.2); work places for the traffic controllers with keyboards, screens, and other devices (as in Figure 16.3); software modules for movement control, communications, and interaction, with parameter settings of various kinds. For the configuration of a complete and correct interlocking for a railway station, thousands of constraints (i.e., dependencies between components and/or their attributes) have to be satisfied. There are

FIGURE 16.2 Siemens rail automation hardware.

FIGURE 16.3 Siemens’ Controlguide operations control center.

202

CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry

constraints on the existence and/or number of components and on the values of their attributes, depending on the existence and values of other components; for example, each electric light signal in the field requires the existence of an adequate hardware module, a module of type “M8” can control a maximum of eight lamps, the usage of LEDs excludes other lamp types on the same module, and so on. The configuration process for a specific station uses information about the field elements (names, track layout, speed limits imposed by properties of the environment such as downward slope, curve radius, etc.) and about the interfaces to neighboring stations and traffic controllers. From this information, all the data (parameters) needed by the railway interlocking system have to be derived and in some cases adjusted by the configuration engineer, taking into account the features provided by the selected technology (type of interlocking system). The engineer has to be informed about the alternatives in order to make an existing inconsistent configuration consistent (e.g., which components to add or delete, which values to change). Figure 16.4 shows a schematic representation of the configuration of a railway interlocking system. The upper left part represents the station with the railway tracks, points (switches), and signals (similar

Field equipment

Attributes Software configuration for ECC 01.01

Signal "S1": ECC = 01.01 module type = SOM lamp 1 = red lamp 2 = green

Interlock Hardware configuration CPU

POM

SOM

Cable termination rack

FIGURE 16.4 Schematic representation of a railway interlocking.

ECC rack with ECC 01.01 double frame

16.2 Domain: Railway Interlocking Systems

203

Interlocking 1..1

Software 1..*

Station maxElems: [integer] maxRacks: [integer]

Element 1..1

1..1

Control computer 0..*

id: [string]

0..*

0..1

1..1

Rack id: [string]

Frame 0..*

Function 0..* 1..1

1..*

1..1 1..1

1..1

0..*

Hardware 0..*

id: [string] type: [string] nrModules: [1,2,3]

Module

1..1

nr: [integer]

0..*

slotNr: [integer] type: [string] double: [bool]

1..* 1..1

0..*

Bit allocation pos: [integer]

FIGURE 16.5 UML diagram for part of the hardware configuration.

to a real station as shown in Figure 16.1). The interlocking building depicted next to it contains two hardware racks (similar to real racks as shown in Figure 16.2). The left one (cable termination) wires the cables from the field elements (signal lamps, point machines) to the element control computer (ECC). The frame is equipped with element operating modules (e.g., POM, SOM) and a CPU (central processing unit). The latter contains software that represents the topology and attributes of the field elements (e.g., signal “S1”). The configuration of all hardware and software components must be consistent (e.g., all signal lamps must be connected to a SOM module and be controlled by a process in the CPU). See Falkner and Fleischanderl (2001) for more examples for software and monitoring systems, such as configuration of train routes. In more detail, the necessity of modules is driven by the required functionality (e.g., elements in the field). The UML diagram in Figure 16.5 is a small fraction of the UML model for hardware and software configuration. It shows that an interlocking system is in charge of several railway stations. Each station houses an unlimited number of hardware racks with hardware frames of various types. Some frames contain hardware modules that control field elements. Each element is controlled by a process in a control computer. Depending on its type, an element may require certain functions, which are characterized by a set of input and output bits. Each bit is wired to a specific position (allocation) on a hardware module. Additional constraints such as the following (not shown in the figure) restrict the allowed combinations: The modules shall be placed in a frame of a suitable type. Depending on their type, certain functions must be allocated to different modules, others to the same module. Certain bits are to be allocated to specified fixed positions (e.g., the first bit on the first register of certain module types).

204

CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry

The goal is to find a minimal solution of racks, frames, and modules for each station when the elements and their functions (including required bits) are given. The scenario is incremental: functionality (and therefore modules) may be added to an existing configuration.

16.3 Requirements 16.3.1 Variability Although the previous section only gives an overview of the most important components of an interlocking system, it shows the variety and complexity of the problem. There are various subsystems with quite different characteristics, for example: • •

• •

Hardware with many types of different components as well as electrical and spatial constraints. As output for manufacturing, CAD drawings are needed. Software modules with thousands of configuration parameters which depend on other parameters and on the hardware. They must be output in various formats so that they can be loaded into the PROMs of the electronic interlocking. Communication equipment configured to satisfy different network protocols and address spaces. Work places for the traffic controllers comprising monitor screens, keyboards, and other devices.

Because railways have a long history and are considered by operators to be a kind of national culture, different countries have different regulations, equipment, and requirements. Therefore, corresponding variants and versions of the configurator application must be developed, deployed, and maintained in parallel. The applications and use cases range from single installations (market entry in a country) to “mass” production (several stations for one country). In the first case, it is vital to keep the costs for countryspecific adaptations of the configurator low, for example, by giving the project engineer much freedom to configure the system according to the country’s special requirements. In the second case, it is vital to keep the costs for station configuration low, for example, by increasing the automation degree of solution finding. This kind of semi-interactive usage (a combination of manual editing and automatic completion) is also important when regulations change and a station configuration has to be adjusted accordingly before the change is implemented in the configurator.

16.3.2 Complexity The inherent structure of the model is not only a tree as supported by most of the tools that are based on a BOM (bill of materials) structure such as feature modeling (Asikainen et al., 2006). Rather, it is a network, for example, for wiring between hardware components, for train routes in the track diagram on the traffic controller’s screen, and so on. Typically, each element (e.g., signal “S1”) has interacting representations in different subsystems (e.g., lamps in the hardware, parameters in the software, menu items on the traffic controller’s monitor, etc.). This leads to complicated consistency and completeness conditions (e.g. that a train route from one signal to another must be a path of connected elements without loops and with a unique choice of switch positions if alternative paths exist). Large stations can have hundreds of tracks with a similar number of axle counters or track circuits, hundreds of sets of points (switches) with one or two machines each, hundreds of signals with a total

16.3 Requirements

205

of thousands of lamps, and many other devices such as level crossings and section blocks. All these devices are wired with the computers in the interlocking building where tens of thousands of pins must be connected. The number of elements is multiplied by the different software modules in which they occur. In addition, there are thousands of train routes. Taking into account the fact that all these components may have several attributes and relations (associations) to other components, the number of variables can run up to hundreds of thousands. As most of them are not only Boolean values, but enumerations or integer values, the number of possible configurations is enormous. The configuration task must be able to handle dynamic growth of the system. The number of components is not known beforehand. Depending on the number of tracks, points (switches), signals, and other elements at the station, hardware racks and modules have to be supplied. The project engineer might decide to pack the modules tightly, or leave a certain amount of slack for future station extensions. In the second case, the user is not interested in a minimal solution and therefore plain optimization algorithms are not useful.

16.3.3 Evolution Railway interlocking systems have a long lifespan (20 to 40 years). During that time, not only the station layout may change (due to adding or removing tracks, signals, or other equipment) but also the spare parts of the interlocking hardware may be changed to newer versions with different characteristics. Although the knowledge base is not as volatile as for consumer products, there is a change rate of about 10% per year (based on the number of classes, attributes, and constraints). Most changes are caused by new component types or new software functionality. However, constraints may change as well when regulations change (e.g., longer braking distances required) or when experiences from the operations lead to new procedures for manufacturing (e.g., two modules of a certain type are not to be placed next to each other because the resulting increase in heat might reduce their lifetime). Typically, old types cannot be removed from the knowledge base because they are still in use in existing configurations. Constraints must take into account the possible interrelations between all those old and new components and features. Proper tools for easy maintenance of the knowledge base are required. If the interlocking system has to be changed, due to either changes of station layout or the replacement of damaged components, an upgrade to the current knowledge base may be necessary. This can lead to constraint violations because the existing configuration no longer complies with the new knowledge base. In some cases, the necessary reconfiguration can be done automatically (such as setting new properties to their default value); in other cases, user decisions are required (e.g., in case an existing hardware module is no longer allowed in its current position, it is either to be moved to another position or replaced by a newer version which is allowed there). Falkner and Haselböck (2013) describe the main issues that arise in such situations and Friedrich et al. (2011) summarize important theoretical and practical aspects of formalizing reconfiguration problems.

16.3.4 Other Issues The preceding paragraphs concentrate on knowledge representation and reasoning issues of the core configuration task. Of course, the configurator application as a whole has to deal with much more: Sales and pricing topics play a role in the bidding phase, although not as prominently as in consumer products’ configurators. Usability is directed at serving professional engineers, thus the graphical user

206

CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry

interface must be clearly understandable and functional but need not be too elaborate. A very important topic is interaction with other systems or data sources: reading information about the station, generating outputs and documentation in various formats for manufacturing, reviews and assessments, access to product data in the management system (e.g., SAP). Last but not least, there are general issues such as authorization, collaboration, database management, version control, and so on.

16.4 Techniques A short survey of the available commercial configuration frameworks and tools at the beginning of the development project showed that they were either not expressive enough (e.g., supporting only a flat set of variables and constraint tuples) or not efficient enough (e.g., solvers based on backtracking, backjumping, etc.). It was decided to create a powerful generic framework and specialization layers for domain-specific requirements for railway safety systems. See Haselböck and Schenner (2014)4 for a detailed description of the generic framework (S’UPREME). Most of the structures and requirements are similar for different railway companies (e.g., tracks, signals, train routes, etc.). However, they differ in some—sometimes many—details. For instance, sets of available hardware elements are different in different countries, rules about how to connect components vary, or special user interface views or import/export formats are needed. Therefore, the architecture of a S’UPREME configurator for railway safety systems consists of three layers (see Figure 16.6): • • •

The domain-independent kernel of the S’UPREME framework, providing mechanisms for knowledge base representation, constraint-based reasoning, and generic user interfaces The basis layer, containing all railway and technology knowledge that is common to all configurator variants The variant layers, representing the specialties of different countries and customers

In the basis layer for railway safety systems, some domain-specific implementations deal with special requirements, especially concerning input/output. The configurator reads tables (e.g., Excel) specifying customer requirements and checks their consistency (including cross-references between input tables). A template-based generator for outputs makes it easier to create documentation in various formats (XML, PDF, Microsoft Word, Excel, etc.).

Variant layers Basis layer

KB(variant) (variant) Constraints Constraints(v) (v) UI UI(variant) (variant) KB KB (variant) Constraints (v) UI (variant) KB (basis)

Constraints (b)

UI (basis)

S‘UPREME kernel

FIGURE 16.6 Layers of a S’UPREME configurator. 4 Chapter

22.

I/O(variant) (variant) I/O I/O (variant) I/O (basis)

16.4 Techniques

207

Object-oriented design uses concepts in a modeling language that is highly expressive and allows the implementation of those layers and the representation of the application domain in a natural, understandable way (taxonomy, partonomy, classes, attributes, associations). Therefore it can well deal with the complexity of the domain and with the interfaces to UI and to other systems (import/export). The implementation language is Java and thus platform-independent. Generative constraint satisfaction extends the object-oriented model with constraint technology. The attributes and associations of the model are used as variables of a constraint satisfaction problem. See Haselböck and Schenner (2014)5 for details. Reasoning over those structures is harder than for classical CSP (constraint satisfaction problems). Some provisions enable the system to deal with configurations as large as typical interlocking systems: •

•

•

•

•

The system manages all dependencies between variables and can therefore update each active constraint on the fly. This is used for showing the user always an up-to-date violation status as well as for a straightforward explanation mechanism. The standard solving strategy is a heuristic local search based on a greedy repair mechanism (not a complete search). Violated constraints indicate parts of the configuration that need to be repaired. The user can repair a constraint violation manually by choosing from a list of possible repair steps. Alternatively, the solver can be started to solve the constraints according to the solver’s current heuristic. Rules can be used if the inference is always to work in one direction only (e.g., always generating hardware modules for field elements, never generating field elements for hardware modules). In such cases, they are more efficient than constraints. The S’UPREME rule mechanism can be used in parallel with constraints. Usually, the configuration of a large system consists of different subtasks (hardware configuration, software configuration, etc.). The constraints of such subtasks can be grouped in clusters that can be deactivated when currently not in the user’s focus. Thus, they are ignored by reasoning until they are activated again. Each of those clusters can be assigned a specialized solver. Thus, in order to tackle certain subproblems, optimized (also third-party) solvers can be used (e.g., for solving linear programming (LP) problems).

Reconfiguration is supported by several strategies: •

• •

After upgrading an existing configuration to a new knowledge base version, constraint violations indicate the parts in the configuration that are now outdated and should be reconfigured. These constraint violations can either be repaired manually, giving the user full control over the process, or automatically by special-purpose solvers that try to minimize changes to the configuration. By keeping the model of the configurator backward-compatible with all previous versions, it is possible to represent systems that were built years ago. In order to improve schema evolution, multistep upgrades have been introduced (i.e., only one user interaction for upgrading a configuration over several schema versions).

Automated regression tests are used to find the differences between the content of a configuration before and after an upgrade to a new configurator version. This enables mistakes in knowledge modeling 5 Chapter

22.

208

CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry

to be detected at a very early stage and, equally importantly, ensures that the configurations remain stable from one version to the next. This feature is particularly important for railway applications, where all installations—and therefore all changes to existing installations—must run through intensive quality assurance and validation procedures. There are two groups of regression tests: small test cases, which test partial configurations with respect to one constraint each (typically designed during development), and large test cases comprising many different features in order to get a high coverage of various configurations and values (typically designed by the integration team at the start of the project). Of course, all these tests must be checked and possibly adapted when change-requests are implemented in a new version. The advantages of using a standard IDE (integrated development environment) such as Eclipse are exploited: It supports knowledge engineering with state-of-the-art editors (code completion, diagrams, etc.), debugging facilities, test environment, and version control. Iterative and incremental processes for knowledge engineering are important practices to guarantee customer satisfaction and high quality. In particular, they are necessary for correctly modeling the domain and product details as information from various sources has to be integrated: written technical specifications for the numerous parts of the configurable product, (tacit) knowledge of all involved engineers, different languages and representations (e.g., semistructured natural language, logical, graphical). Thus, the early and continuous involvement of domain experts during development of the configurator is crucial for success.

16.5 Results The amount of configurator code concerning the core task of knowledge representation and reasoning is often overestimated. In the configurator described in this chapter, the model and constraints comprise only about 20% of the source code. The rest of the code deals with the user interface (UI), the generation of outputs (BOMs, documents, CAD drawings, manufacturing plans, etc.), and testing of the whole application. The layered architecture facilitates reuse considerably. The code size of a typical variant is approximately 10% of the whole application code (a small value, considering that railway companies in different countries have quite different requirements). Standardizing the model and UI (i.e., omitting those packages in the variant layer or reducing them to customization via tables or only overriding certain constraints) has reduced the number of code lines for variants by 40%. Thus, the development time of variants could be significantly reduced as well. Constraints help the user to avoid mistakes, reducing integration cycles and system test time. Rules and solving steps create objects and set values automatically, leading to productivity increases for the user by a factor of 10 and higher, compared to configuration tools used earlier: • •

For a specific country variant, the configuration effort of the first version of an interlocking system could be reduced from eight to two weeks. A similar speed-up of 70% for the core configuration process was evaluated in a study of the Siemens business unit responsible for a new type of interlocking system in a country where several stations had to be equipped. They compared the tool for the new technology (which included tables with customer information) with an existing tool for a similar technology.

References

•

209

With the help of the configurator variant for a new axle counter system (developed in less than a year’s work), the degree of automation with solvable constraints and rules was so high that 95% of the configuration could be derived within a few seconds, once the station layout had been drawn in the tool (requiring only a few hours’ work). Although such a system is much smaller than an interlocking system, it still consists of 50 classes with 300 attributes and associations and 200 constraint definitions. Average configurations consist of 2,000 instances, 30,000 variables, and 30,000 constraint instantiations.

Multistep upgrades have reduced development time for the upgrade by an estimated 50% of the upgrade coding time, as well as the users’ time for upgrading configurations to 1/N for each upgrade, N being the difference between source and target version numbers (i.e., the number of single-step upgrades).

16.6 Conclusion The sections above have presented the rationale and impacts of using product configuration technologies in a configurator framework for large-scale industrial systems (railway interlockings). All in all, development could be accelerated compared to an alternative where only standard object-oriented programming languages would have been used: • • • • •

Multiple usage of constraints (for checking, filtering, explanation, and repair) as well as their compact format reduced the size of the corresponding code parts by approximately 30%. Maintenance is easier due to the declarative representation of the constraints (separation from solving algorithms). Schema evolution and automatic database upgrade could be implemented more easily. Training time of new knowledge engineers was reduced to approximately one half. Compared to an analogous rule-based system, an estimated 20% of bugs were avoided. Thus, configuration technologies can definitely help to reduce project costs.

References Asikainen, T., Männistö, T., Soininen, T., 2006. A unified conceptual foundation for feature modeling. In: 10th International Software Product Line Conference (SPLC 2006). IEEE Computer Society, Baltimore, MD, pp. 31–40. Falkner, A., Fleischanderl, G., 2001. Configuration requirements from railway interlocking stations. In: 17th International Joint Conference on Artificial Intelligence (IJCAI-2001), Configuration Workshop, Seattle, WA, pp. 15–17. Falkner, A., Haselböck, A., 2013. Challenges of knowledge evolution in practice. AI Communications 26 (1), 3–14. Falkner, A., Haselböck, A., Schenner, G., Schreiner, H., 2007. Benefits from three configurator generations. In: Innovative Processes and Products for Mass Customization (Proceedings of the joint conference of the International Mass Customization Meeting 2007 (IMCM’07) and International Conference on Economic, Technical and Organizational Aspects on Product Configuration Systems (PETO’07)). Series on Business Informatics and Application Systems, vol. 3. GITO, pp. 89–103.

210

CHAPTER 16 SIEMENS: Configuration and Reconfiguration in Industry

Fleischanderl, G., Friedrich, G.E., Haselböck, A., Schreiner, H., Stumptner, M., 1998. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems 13 (4), 59–68. Friedrich, G., Ryabokon, A., Falkner, A.A., Haselböck, A., Schenner, G., Schreiner, H., 2011. (Re)configuration based on model generation. Second Workshop on Logics for Component Configuration (LoCoCo 2011), Perugia, Italy, pp. 26–35. Haselböck, A., Schenner, G., 2014. S’UPREME. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 263–269 (Chapter 22).

CHAPTER

Tacton: Use of Tacton Configurator at FLSmidth

17

Klas Orsvärn* and Morten H. Bennick† * Tacton, † FLSmidth,

Stockholm, Sweden Copenhagen, Denmark

Abstract: FLSmidth is a leading vendor of equipment for cement plants, with a long experience of using software to support product configuration in making proposals as well as in order processing. This paper describes their experience implementing Tacton Configurator, integrated with various other systems such as SolidWorks 3D CAD, SmartPlant 3D, Mathcad, and legacy ERP. Integration was found to be a critical success factor. Other critical success factors were the use of a powerful constraint-solver engine as well as product experts dedicated to configuration modeling. We describe the identified business benefits such as improved productivity, shorter lead times, standardization, higher quality, and increased market share.

17.1 Introduction FLSmidth is the world’s leading supplier of complete cement plants, as well as a leading supplier of plants and equipment for minerals processing. We begin by describing the company and its business. We briefly describe their previous experiences of using configurators and why Tacton Configurator was chosen to replace them. One critical success factor was the use of a powerful constraint-solver, thus, we describe the advantages and some of the important requirements of such a configurator. The company has appointed a dedicated team of engineers to take care of most of the configuration modeling. Integrations to related business and engineering systems are important for reaching the full benefits of configuration systems (Tiihonen and Soininen, 1997). We describe the integrations of FLSmidth at a high level. Finally, we describe the identified business benefits and draw some conclusions.

17.2 FLSmidth Company Introduction Headquartered in Copenhagen, Denmark, FLSmidth employs approximately 14.000 people around the world, most of whom are engineers. Although most of the products are designed by FLSmidth, most of its manufacturing is outsourced to suppliers. FLSmidth strives continually to improve efficiency and quality. For that reason, the company has been at the forefront of industrial equipment vendors in using software to support engineering and handling of product data. FLSmidth has acquired a lot of companies that supply related equipment, which exemplifies a strong trend in the industrial equipment sector; to consolidate and become a onesource supplier of a complete end-to-end manufacturing process solution. This also means that staff Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00017-7 © 2014 Elsevier Inc. All rights reserved.

211

212

CHAPTER 17 Tacton: Use of Tacton Configurator at FLSmidth

involved in the process from customer inquiry to order fulfillment must handle a very wide range of products, which makes the use of product configuration tools essential for generating quotations— calculating the cost and price, producing proposal documentation that describes the proposed solution, and processing orders to systems for manufacturing execution and supply chain.

17.3 Cement Plants The size of a complete cement plant is gigantic, in the order of one kilometer long, and the biggest product can be over a hundred meters high (Figure 17.1). The input to a cement production plant is raw materials such as limestone and clay. The process of producing thousands of tons of cement per day from this input consists of numerous steps including crushing, grinding, mixing, heating, and cooling. Each step is performed by one or several configurable products. Between and within all these processes, the materials are transported via various types of conveyors, mechanical as well as pneumatic. In total, a cement plant consists of hundreds of configurable products, most of them designed by FLSmidth. Each product is highly configurable in its own right, many of them consisting of thousands of components. The configurator software must be able to configure the individual products one by one, but also to configure the whole system of products. The equipment configuration depends heavily on the specific properties of the raw materials at hand at the customer site, choice of different techniques, capacity

FIGURE 17.1 A cement plant supplied by FLSmidth.

17.4 The Choice of Tacton Configurator

213

requirements, available space, and so on. In all products, reducing pollution and energy consumption is very important. The configurator must therefore be able to integrate with sizing calculations to take those application requirements into account. Although layout decisions are made by the plant designer, by using the plant design software, the configurator must be able to parameterize product configurations so that components can be customized automatically in terms of dimensions and positions to comply with the spatial requirements driven by the layout. The configuration requirements of FLSmidth are typical for industrial equipment; a seemingly standardized process requires a vast range of variation due to differences in the capacity, properties of the input and output, efficiency requirements, automation, environment, safety, reliability, available space, and so on. The combinatorics result in billions of potential combinations even in a single product. It is relevant to compare with the configuration requirements of consumer products, since those are much more well known. Products for individual consumers are typically standardized catalog products sold via retailers in very large volumes. Industrial customers are more specialized and therefore demand more variation. In addition, each niche of industrial equipment is small in terms of the number of units sold compared to consumer products. This means that economy of scale does not drive as strongly toward standardized catalog products. The concept of one size fits all does not pay off here. The additional cost of customization is less when the volume is low. Mass customization is a growing trend in consumer products, but customization has always been a necessity in industrial equipment markets.

17.4 The Choice of Tacton Configurator After using in-house developed configurators, FLSmidth switched to using Baans sales configurator in year 2000, for proposals as well as for order processing. That implementation has been described in Hvam et al. (2008). In 2008, the decision was made to replace that with Tacton Configurator.1 Multiple reasons contributed to that decision: • •

• •

1

Initially, Tacton Configurator was evaluated as a solution to generate 3D models and drawings in SolidWorks, for proposals and manufacturing, something that was not possible with the sales configurator from Baan. In this evaluation, FLSmidth were impressed by the ease of use and robustness of Tacton Configurator as a product configurator and sales configurator. The use of Baans sales configurator had made the organization appreciate the ease of use of constraint-based configuration, in terms of interactivity and ease of maintenance (see Section 17.5). Furthermore, Tacton Configurator was perceived as an even stronger constraint-based solution (e.g., by the ability to mix the constraint-based evaluation with sequential processing when needed, and separating the model of the user interface from how it should be rendered). There are obvious benefits in using the same configurator for sales, order processing, and design automation in CAD, to avoid maintaining and using multiple systems. Tacton had good customer references with similarly complex industrial equipment products configured as complete production systems by the configurator (e.g., TetraPak, Sidel, and Siemens Turbomachinery). www.tacton.com.

214

•

•

•

CHAPTER 17 Tacton: Use of Tacton Configurator at FLSmidth

FLSmidth liked that Tacton, as a company, was dedicated to configuration, yet big enough to handle their needs (over 50 employees at the time and now more than 100), and with a long track record of deploying and enhancing the configurator for over 10 years without impairing backward compatibility. When replacing the existing Baan configurator, it was also important that Tacton Configurator is XML-based and designed to be embeddable in other applications. FLSmidth were able to reuse existing integrations to legacy systems, and the user interface could be tailored to the organization’s way of working, consistently across all products. Tacton Configurator survived months of intensive testing to ensure that the complex requirements would be met.

17.5 Advantages and Requirements of Constraint-Based Configuration The advantages of using a constraint-based solver engine for product configuration are well known (DeSisto, 1997; Junker, 2006). A constraint-based interaction empowers the user to explore the vast space of configurations and find the best solution for the customers needs: • •

•

Since many input combinations are invalid, it is important that the end-user is able to explore the possibilities by making choices in his/her preferred sequence and then view how each choice affects available alternatives for other choices. To find the best solution, it is sometimes necessary to make trade-offs between conflicting choices. This can be achieved by showing the user which alternatives are incompatible with previous choices and automatically inform the user how an invalid alternative can be made valid by making trade-offs with previous choices. Since customer specifications are typically incomplete, the constraint-solver engine should be able to validate incomplete input and find a good solution for the unspecified inputs. It should be possible to optimize the solution based on any attribute, such as cost or lead-time, or to guide the search with soft preferences.

Rules maintenance is another important challenge. We use the term rule here to denote the real-world dependency between configuration decisions, and constraint refers to the encoding of such a rule for processing by a constraint-based engine. From a rules maintenance point of view, an advantage of using a constraint-based engine is that each constraint is independent and does not assume a sequence of rules processing. This means that each configuration rule in the product can be encoded independently as a constraint without taking the other rules into account, so a rule can be added, revised, or removed without affecting the encoding of other rules. This is very important since the rules can usually not be documented from the beginning and they frequently change as the configurable product evolves over time. The difficulty of documenting all the rules before encoding them in a configurator is that it is hard for product experts to articulate all their knowledge. During testing and use of the configurator, they therefore realize that important rules have been forgotten and need to be added. Similarly, configuration rules are often controversial and subject to change by design revisions. It is therefore essential that each rule can be encoded independently. With a sequential rules engine, such

17.6 Implementing Tacton Configurator at FLSmidth

215

changes to the rules that are relatively small at a conceptual level can require large changes in the encoding, due to the sequential dependencies in the encoding. This can become prohibitively costly and drastically delay time-to-market. In order to achieve these interaction requirements without additional costly and delaying rules programming, it is important that the constraint-based engine is a powerful constraint-solver, so that the interactivity is achieved automatically based on the constraints. Beyond the constraint-solver capabilities, configuration of complex industrial equipment has the following additional requirements on the constraint-solver, and the evaluation by FLSmidth concluded that Tacton Configurator meets these requirements. Many products are dynamic in nature. The number of component instances may vary depending on capacity requirements, and each instance may require individual configuration. In a cement plant, typical examples are products where the number of segments vary depending on length and height, such as a conveyor. This requires a constraint solver with the ability to dynamically generate new variables. For complex products, it is not always feasible for the configurator to access all relevant data from the beginning of the configuration session, for example when the relevant component data depends on capacities and decisions that are not known from the beginning. This requires the ability to dynamically access more data on demand during the configuration session. Complex product configuration often involves sizing calculations. The constraint solver must have the ability to apply complex mathematical functions and invoke external calculations at run-time, feeding the results into further constraint processing. Configurable products may have freely customizable parameters such as dimension and positions, like the beams and support points in a conveyor. To handle this well, the configuration model must be parametric throughout the product hierarchy, and variables must be able to range over large integer or floating point domains. The space of potential combinations to consider in a configurable product can be greater than the number of atoms in the observable universe. Although the problem of finding a solution tends to be manageable in products designed for configuration, it can for highly complex products be infeasible to solve in acceptable response time with a general purpose algorithm. It is important to also have mechanisms to guide the search heuristically in terms of the sequence of decisions without redundant encoding of constraints.

17.6 Implementing Tacton Configurator at FLSmidth 17.6.1 Configuration Modeling Configuration modeling is the work to define the generic product structure, configurable parameters, constraints, and such in the configurator software. After an introductory three-day training session, the FLSmidth engineers were able to do all the required modeling work by themselves, using the remote product support of Tacton. The configuration modeling was initially done at the headquarters in Copenhagen. But since most of the engineering is today done at FLSmidth’s office in Chennai, India, the configuration modeling has mostly been taken over by a team of engineers there. They have very good knowledge of the products and their applications, which reduces the overhead of communication

216

CHAPTER 17 Tacton: Use of Tacton Configurator at FLSmidth

FIGURE 17.2 A 3D model of a cross bar cooler, generated by Tacton Configurator and SolidWorks.

with specialists to define the rules. By using dedicated resources for configuration modeling, they can gain the experience required to model complex products.

17.6.2 Product Scope Tacton Configurator was taken into production use at FLSmidth in 2009, and is now used around the world for about 50 different products, covering the major parts of a cement plant (e.g., belt conveyors, screw conveyors, air slides, drag chains, material elevators, nuisance filters, process filters, fans, mills, kilns, and coolers).2 One example cooler product is shown in Figure 17.2.

17.6.3 Integrated Calculations The FLSmidth system can integrate the configurator with any external service. They currently use Mathcad for complex equipment sizing calculations like integration, differentiation, and matrix calculations. 2 See

www.flsmidth.com for additional information about these types of products.

17.7 Benefits

217

Mathcad runs invisibly on the server behind Tacton Configurator. The end user does not even realize when the program calls the external service (e.g., Mathcad) to perform a calculation.

17.6.4 Output The following kinds of output can be generated by Tacton Configurator at FLSmidth: • • •

Configured product BOM structure to the legacy ERP system Atlas. 3D models and 2D drawings in various formats, generated by the SolidWorks integration, for proposals and manufacturing. Proposal documentation in PDF format.

17.6.5 Integration to SmartPlant 3D FLSmidth are introducing a plant design software called SmartPlant 3D, from Intergraph. This tool is used to design the plant process and layout. In order to streamline the process, FLSmidth have developed an add-into SmartPlant that allows them to run Tacton Configurator within the SmartPlant user interface, to ensure that the products in the plant are correctly configured, with correct 3D models at the plant design level. The same configurations can then be accessed in the web-based configurator to generate additional documentation, mechanical CAD documents based on SolidWorks, and to process equipment orders into the ERP.

17.7 Benefits The following are the main business benefits of the configurator perceived at FLSmidth.

17.7.1 Less Time Spent on Product Configuration Without a configurator, it took hours to configure one product, and now it takes a few minutes. This applies to proposals as well as to order processing. A plant can contain hundreds of different configurations (many different configurable products and many different configurations of some of those products), so it adds up to a lot of time savings.

17.7.2 Shorter Lead Times When product configuration required involvement of a few specialists, this created long lead times for proposals and order processing, beyond the effective time spent. This challenge has grown over time. FLSmidth used to have all the engineering specialists at the headquarters in Copenhagen, but has now acquired companies with different products all around the world. The product expertise is more spread out. Since FLSmidth sells complete plants with products from different places, this global distribution makes it more complicated and time consuming to generate proposals and process orders. Tacton Configurator eliminates this complication by making the expertise available anywhere. Lead times for all the product configurations in a project can be reduced from months to days.

218

CHAPTER 17 Tacton: Use of Tacton Configurator at FLSmidth

17.7.3 More Standardized Configurations Without the configurator, specialists tend to create special proposals that are more customized than necessary. The configurator enforces a standardization that reduces the cost of supplying the products.

17.7.4 Improved Quality of Configurations There are an extreme number of rules to obey in configuring a cement plant. Not just product configuration, but also rules about the cement production process as well. The human element increases the risk of mistakes, and it is not feasible to involve specialists in every revision made in a project. The use of the configurator thereby reduces the risk of incorrect configurations.

17.7.5 Increased Market Share With the drastic cuts in lead time and cost of proposals, FLSmidth can now make more proposals and gain a bigger share of the market.

17.8 Conclusion This paper has presented FLSmidth and their experience of implementing Tacton Configurator for their cement plant products. Critical success factors are: a powerful constraint-solving engine supporting a high degree of interactivity and ease of constraint modeling, integrations to sizing calculations, integrations to related systems such as 3D CAD, plant design, and legacy ERP, as well as resources dedicated to configuration modeling who are skilled engineers knowledgeable about the products and their applications. A lot of resources are required for modeling and integration, but the benefits are very significant for the business.

Acknowledgments Kristin Lund provided valuable assistance in gathering data and editing. SolidWorks is a trademark of Dassault Systèmes. SmartPlant is a trademark of Intergraph. Matchcad is a trademark of Mathsoft.

References DeSisto, R., 1997. Constraints Still Key for Product Configurator Deployments. Technical Report T-22-9419, Gartner, Stamford, CT. Hvam, L., Mortensen, N., Riis, H., 2008. Product Customization. Springer, Berlin, Heidelberg. Junker, U., 2006. Configuration. In: Rossi, F., vanBeek, P., Walsh, T. (Eds.), Handbook of constraint programming. Foundations of Artificial Intelligence, vol. 2. Elsevier, Amsterdam, The Netherlands, pp. 837–873. Tiihonen, J., Soininen, T., 1997. Product Configurators - Information System Support for Configurable Products. Technical Report TKO-B137, Helsinki University of Technology, Laboratory of Information Processing Science, also published in: Increasing Sales Productivity through the Use of Information Technology during the Sales Visit, Hewson Consulting Group.

CHAPTER

encoway: From ERP-Based to Sales-Oriented Configuration

18 Björn Höfling encoway, Bremen, Germany

Abstract: ERP-based product configuration is often used for supporting business execution processes in companies. Reusing the underlying product configuration models in sales-oriented scenarios leads to additional challenges. In this chapter we describe a sales application called sellAIR, which is the outcome of joint project work of encoway and the German company Boge. With this application, Boge has succeeded in closing the gap between ERP-based product configuration and sales-oriented configuration.

18.1 Introduction: ERP-Based Configuration Systems for enterprise resource planning (ERP) are integrated software applications for the automation of business processes. Typical examples of such processes in ERP systems are quote and order processing or production planning. For those companies that produce or deal with complex products with a high number of variants, some ERP systems support knowledge-based configuration. Depending on the specific market or supported scenarios, different knowledge representation and reasoning techniques are implemented in these systems. One of the major challenges to be addressed when manufacturing complex products can be summarized by the concept of mass customization, which tries to combine the advantages of mass production with the flexibility of individual customization (see Piller and Blazek, 20141 ). Configuration systems are a key-enabling technology of mass customization. A simple way of categorizing the application areas of (knowledge-based) product configuration in ERP systems can be shown along with the order fulfilment process. Make to stock (MTS) is a build-ahead production approach that supports mass production. In contrast, individual customization can be done in projectoriented production. In between, the scenario of make to order (MTO) is placed, which can be supported with the help of product configuration. Here, the production process is triggered by a sales order that includes the specific definition of the configurable products in the order. The German software corporation SAP AG is a big player in the enterprise application software market (see also Haag, 20142 ). Its enterprise resource planning application is called SAP ERP, which includes a variant configurator called LO-VC (module logistics, variant configuration). Variant configuration is a basic technique that can be used in different business processes inside SAP ERP. The LO-VC can be applied in the modules PP (Production Planning), SD (Sales and Distribution), 1 Chapter 2 Chapter

9. 27.

Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00018-9 © 2014 Elsevier Inc. All rights reserved.

219

220

CHAPTER 18 encoway: From ERP-Based to Sales-Oriented Configuration

MM (Materials Management), CO (Controlling), CA (Cross Application Components), and CRM (Customer Relationship Management). Concerning knowledge representation and reasoning mechanisms, the LO-VC combines different approaches that lead to a high expressiveness for product configuration models. Both declarative and procedural modeling are supported through the following major modeling primitives for dependencies between different kinds of objects: • • • •

Constraints for assigning or checking values in a declarative way by evaluating (in)equations, variant tables, or variant functions Procedures for assigning or changing values taking into account the defined sequence of operations (e.g., value assignments, price calculations, visibility changes, and dynamic default setting) Preconditions for (dis)allowing values with the help of Boolean expressions Selection conditions for including parts in bills of materials

Monotonic behavior of characteristics (a value range can only be reduced during configuration and not enlarged) can be modeled by choosing so-called restrictable characteristics in combination with reducing their values with the help of constraints. The full extent of variant configuration with SAP is described in Blumöhr et al. (2012). For a comparison between the declarative and procedural approach of variant configuration with SAP, see Haag (2010). The remainder of this chapter is organized as follows. Section 18.2 describes in more detail our view on sales-oriented configuration together with its product models and functional requirements. Section 18.3 provides a concrete case study named sellAIR at the German company Boge. First, requirements are discussed. Thereafter, we present the architecture of the application. We conclude this chapter with a discussion of the achievements of the deployed sellAIR application.

18.2 Sales-Oriented Configuration Obviously, a company’s sales force would like to have access to their product configurations for being able to make valid statements (technical and commercial) toward customers. But there are many cases where this cannot be done via direct access to the SAP ERP. In addition the ERP product model itself might be necessary but is often not sufficient for the support of sales processes. Vendors of complex configurable products typically have invested a high amount of know-how and modeling time, which is frequently in the area of dozens or hundreds of person-years. This knowledge is manifested in the product model of SAP LO-VC, which is constantly maintained and kept up to date. This is also the right place because it supports many core business processes of the company. Duplicating this product model for sales force requirements would implicate all the disadvantages of redundant data management. Therefore, this big amount of knowledge should be made available for processes that are not directly integrated into the ERP processes without redundancy and should follow the principle of single source of data with SAP ERP as the leading system. Figure 18.1 illustrates how business execution processes in SAP ERP and sales-oriented processes in external applications can share models. Typically, a configuration model in SAP can be divided into two parts. The high-level configuration is situated in SD (sales and distribution). It is interactive; that is, the user makes configuration decisions in a quote by assigning values to product characteristics of the

18.2 Sales-Oriented Configuration

221

FIGURE 18.1 Sales-oriented configuration vs. ERP-based product configuration, with the high-level configuration model of sales and distribution (SD) being shared.

different line items. The result of this configuration is handed over to the low-level configuration, which is situated in PP (production planning). This configuration is not interactive but determines starting from the results of the high-level, the bill of material (BoM) and the routing. As the knowledge base for the low-level is usually not needed in a sales-oriented process, only the high-level model should be exported and reused.

18.2.1 Product Models for Sales-Oriented Configuration Reusing an ERP configuration model as is (without changes) for sales scenarios can be very attractive. But in many cases it is only a starting point for additional improvements. In the following, we will call this improved model a sales-oriented model in contrast to the source product model from the ERP system. Some of the major reasons for these improvements are: •

•

Entities such as customer applications or machines, context, and environment are not suited for being handled in SAP LO-VC. Only objects used in the logistic processes like products or services can be modelled as so-called configurable materials where any configuration knowledge is attached. In the ERP system such a configurable material is also the only possible starting point for a configuration. But in the early phases of sales-oriented configuration whole ranges of products may be relevant with at least parts of their dependencies. In SAP inferences can only be made when the list of possible configurable materials has been reduced to exactly one.

222

•

•

CHAPTER 18 encoway: From ERP-Based to Sales-Oriented Configuration

Besides a rather simple variant of part-of relation between all parts of the BoM of a configurable material (see Blumöhr et al. (2012), especially on the principle of so called super BoMs,) no other relation types between instances are allowed. Often, people with solution or sales know-how don’t have the necessary SAP background and need easier ways of modeling complex dependencies (see Krebs (2014)3 on the encoway Configuration Environment for one possibility).

These reasons lead to the necessity of a higher expressiveness concerning knowledge representation. The following modeling primitives can potentially be added or modified to get from a product model to a sales-oriented model (with the wording of SAP in parentheses): • • •

Concepts (classes) with parameters (characteristics) including information about defaults, visibility, and the GUI model Partonomies (BoM), either bottom-up (from products to systems and solutions) or top-down (from products to, e.g., spare parts); if necessary with additional relation types (for the spare part relation) Constraints and rules (dependencies) especially for sales requirements including pricing mechanisms and national or local specifics

18.2.2 Specification of Functional Requirements Functional requirements represent the user/customer view on the properties to be fulfilled by a configuration. In the following, we discuss three basic forms of stating functional requirements: (1) before product configuration, (2) during product configuration, and (3) after product configuration. Before product configuration comprises all possible ways in which configuration can be integrated into a sales-oriented software application. This includes especially all ways to navigate to or search for a specific product or system/solution. The starting point in such an application may not be the vendors’ product range but the user’s problem for which he/she wants to get an adequate solution. Even if the user may be able to perform a configuration he/she might not be able to find the right configurable product. One functional task then is to perform a search on the available product range together with a mapping between the user’s requirements and the attributes of the available products. This mapping can be especially difficult if the attribute values are not static for the product but are dynamically defined during configuration (e.g., if the combination of attribute values can identify in a unique way one of the configurable products but each attribute by itself has an open value range when starting the configuration). In addition, the product configuration model in the ERP system may not be intuitive for sales purposes as it is often designed to be optimal for manufacturing purposes. One important functional aspect during product configuration that is very often required is to have different alternatives for the course of action during configuration. The major ones are (1) free configuration and (2) guided configuration, the latter necessitating a complete description of the course of action (e.g., in the form of sequential tabs with a sequence of attributes). Of course, there are other possibilities between these two extremes. Having easy access to related media content is important, especially for explaining complex attributes or values to the user. For example, in the domain of machinery and components a common functional requirement is to have a graphical visualization of the result of the 3 Chapter

23.

18.3 Configurator Application: sellAIR at Boge

223

configuration process, ideally alongside and during the configuration either photorealistic or in 2D/3D CAD. Finally, different and complex ways of supporting changes in user decisions are often required. One example is to allow the choice of attribute values that are forbidden by the knowledge base by doing a replay of all other decisions that can be successfully evaluated without conflict. Those decisions that are not possible in combination with the last one are then presented to the user so that he/she can decide about her/his priorities. After product configuration covers all logistic processes that rely on the results of the previously mentioned steps. This includes defining the structure of the enclosing document (e.g., quote or order) in a way that supports the sales process. Complex and adaptable pricing mechanisms such as discounting and scaled prices must be supported. A very important functional requirement of almost all sales applications is the generation of attractive documents, for example, for proposals. As this is the final outcome of the process it should try to attract the attention of the customer and influence his/her decision in a positive way. Documents generated from ERP systems achieve this goal often in a suboptimal fashion. Finally, the result of the configuration process should be transferred back to the business process, especially to ERP or CRM. This means, for example, the creation of an offer document in ERP. Finally, all previously mentioned steps are integrated into a graphical user interface (GUI). Of course, common requirements for this kind of sales applications apply such as conformity to a corporate design and usability optimization. In our case we want to mention two specific issues. Sales applications reusing ERP configuration models usually have much higher expectations concerning the UI compared to their counterparts in ERP because this software can also become their “face to the customer.” The other aspect is the availability of all necessary languages for the sales force including those languages available in the ERP system but not limited to them. Quite frequently not all local sales organizations of a company are running SAP ERP which can lead to missing languages.

18.3 Configurator Application: sellAIR at Boge Boge is an owner-managed German company founded in 1907 by Otto Boge. It produces compressed air systems for many different application areas, has more than 500 employees, and exports to more than 80 countries in the world. As compressors and other components have a high variability, Boge uses the LO-VC in SAP ERP for product configuration. Therein, approximately 600 configurable products are represented with up to 40 characteristics each. All kinds of modeling primitives for dependencies in LO-VC are used, which means a combination of procedural and declarative modeling. In addition, Boge cooperates with the German company encoway and uses their configuration environment (see Krebs, 20144 ). Boge and encoway together have implemented in 2007/2008 a sales application called sellAIR. This application was functionally enhanced over time. Figure 18.2 shows a screenshot of this application during the configuration of a product.

18.3.1 sellAIR: Application Requirements Besides the reuse of the mentioned 600 SAP product models, Boge wanted to be able to define solutions/systems for customers. Such a system can include, for example, a compressor, an air filter, an air 4 Chapter

23.

224

CHAPTER 18 encoway: From ERP-Based to Sales-Oriented Configuration

FIGURE 18.2 sellAIR: user interface of a sales-oriented configurator.

receiver, and some other components. In addition, the characteristics of different application domains for compressed air systems influence the choice and parametrization of the respective components. An important part of every sales-oriented application is pricing. In the case of Boge, gross pricing includes complex variant conditions for the configuration defined in SAP ERP. Afterward, customer-specific discounts and conditions may be added. For Boge this information is maintained in a CRM (customer relationship management) system based on Lotus Notes called SalesAssistant. Therefore an important requirement for sellAIR was an interface to the SalesAssistant. This system should also serve as a resource for all kinds of customer data. The major outcome of sellAIR is a proposal document. It should be attractive as a distinguishing feature compared to the competition of Boge. Product communication (value proposition, unique selling proposition, etc.) must be supported in a very broad way through the possibility of adding additional and individual content together with rich media. The software to be used for the generation of the proposal document had to be Microsoft® Word, as both Boge sales force and dealers wanted to be able to make individual changes later on. The resulting proposal document had to be stored in the CRM system for follow-up processes. In order to have no interruptions in the business execution chain, the resulting line

18.3 Configurator Application: sellAIR at Boge

225

items had to be transferred to SAP ERP in case of an order. Finally, sellAIR has to be available offline for Boge field sales force and online for dealers and potentially in the future for customers also.

18.3.2 sellAIR: Application Architecture Figure 18.3 shows the architecture of the solution fulfilling the given requirements. The involved systems are SAP ERP, the CRM system SalesAssistant, the system d.3 for archiving documents, sellAIR (offline), and sellAIR Web (online). The offline version of sellAIR is used by the sales force of Boge to perform tasks especially at customer sites. It is connected to the SalesAssistant, which is available on all sales laptops. By using the Lotus Notes API, sellAIR has access to all customer data and the generated quote document is stored at the concrete quote object in CRM. For archiving purposes this quote is stored in the d.3 system later on. The customer data and conditions are regularly synchronized between CRM and ERP. The online version sellAIR Web has slightly different goals and users. It is used by customers and dealers of Boge products. Therefore, the functionality has to depend on the respective role of the users. Customers can create baskets with products according to their needs. As a result, they will get a document describing these products in more detail. This basket will then be sent via an email as a request for proposal to Boge and the following process is carried out in the CRM and ERP system.

FIGURE 18.3 Application infrastructure at Boge: distinction between offline version connected to SalesAssistant CRM and online version connected to SAP ERP.

226

CHAPTER 18 encoway: From ERP-Based to Sales-Oriented Configuration

A restricted number of dealers with special rights is allowed to directly transform a basket into an order inside sellAIR Web. The configuration data together with the order header data are handed over to SAP ERP and an order object is created. In addition, an attractive proposal document is created for the dealer, which may be modified and handed over to the dealer’s customer. In order to configure products according to ERP, the necessary high-level product model master data (materials, classes, characteristics, configuration profile with dependencies, variant tables, GUI models, and translations) is transferred from SAP to sellAIR (both offline and online). This is done with the help of the sellAIR builder environment. An update can be easily triggered by Boge whenever changes in the master data occur. sellAIR builder uses a standard software component from encoway, named K-Connect for SAP LO-VC. The data transfer is performed in two steps: (1) extraction and (2) mapping. The extraction process is technically based on remote function calls to SAP BAPI (Business Application Programming Interface) via JCo (Java-Connector). The result is stored into a database. The mapping process takes this database and maps the content into the different structures of the target system (the encoway configuration environment (see Krebs, 20145 )). Dependencies in the SAP variant configurator are available as source code in plain text (following the LO-VC syntax) and have to be parsed and translated from this knowledge representation formalism into the target formalism. A compiler-compiler is used for this task. In the case of Boge, the SAP product model itself has not been altered. A navigation and search hierarchy was added to the products to allow easier access for novice users. Also, additional text and media was added for enhancing the configuration and result visualization together with document creation. On the sales side, the model was enhanced with a knowledge base for configuration of compressed air systems. Besides a compressor, such systems contain other (configurable) components, such as air filters and receivers. After the necessary user decisions are taken for a system, a configuration is started for each relevant component of the system (corresponding to a product in the LO-VC, but running outside SAP in the encoway configuration environment). The configuration result consists of a list of line items each with its dedicated configuration. This list can be processed by the following steps (document generation and quote/order creation). The sellAIR application is based on standard modules of encoway and adapted to the specific needs of Boge and their clients.

18.3.3 sellAIR: Achievements sellAIR was launched in 2008. sellAIR Web has been added in 2011 and is publicly available since 2012. The following benefits have been achieved: • • • • • •

sellAIR replaces an old configuration system with double maintenance of configuration models in SAP and external tooling. An automatic actualization process for product configuration models is established. Product models in sellAIR are up to date and conform to their ERP counterparts. Sales-oriented models are added for system configuration on top of the ERP-based product models. Product and system configuration are available both online and offline. Navigation and search enable fast access to relevant products.

5 Chapter

23.

References

• •

• • •

227

The tooling allows fast, technically correct, and individual proposal creation for Boge sales representatives. A standardized dynamic generation of multilingual and attractive Microsoft® Word documents in different variants for different tasks with homogeneous international layout is one of the major achievements. sellAIR allows comprehensive data exchange with SalesAssistant (CRM at Boge). With sellAIR Web, also customers and dealers profit from the configuration functionality. The results of sellAIR Web can be directly transferred into orders in SAP SD (Sales and Distribution).

18.4 Conclusion We have shown that reusing ERP-based product configuration models in sales-oriented scenarios has many benefits. But additional functional requirements from the sales perspective have to be taken into account. Depending on their placement in the sales process (before, during, or after product configuration), this has different consequences on the configuration task. The spectrum ranges from additional search mechanisms for the right configurable product up to a sales-oriented model for a system or solution on top of the ERP-based product models. The concrete impact of this approach was illustrated with a sales application at the German company Boge.

References Blumöhr, U., Münch, M., Ukalovic, M., 2012. Variant Configuration with SAP, second ed. Galileo Press. Haag, A., 2010. Declarative modeling at SAP revisited – lessons learnt when applying configuration techniques. In: 19th European Conference on Artificial Intelligence (ECAI-2010), Configuration Workshop, Lisbon, Portugal, pp. 57–59. Haag, A., 2014. Product configuration in SAP – a retrospective. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-Based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 319–337 (Chapter 27). Krebs, T., 2014. encoway. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-Based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 271–279 (Chapter 23). Piller, F.T., Blazek, P., 2014. Core capabilities of sustainable mass customization. In: Felfernig, A., Hotz, L., Bagley, C., Tiihonen, J. (Eds.), Knowledge-Based Configuration – From Research to Business Cases. Morgan Kaufmann Publishers, Waltham, MA, pp. 107–120 (Chapter 9).

This page is intentionally left blank

CHAPTER

Kapsch: Reconfiguration of Mobile Phone Networks

19

Iulia Nica* , Franz Wotawa* , Roland Ochenbauer† , Christian Schober† , Harald Hofbauer‡ , and Sanja Boltek‡ * Graz

University of Technology, Graz, Austria Business Com, Vienna, Austria ‡ Kapsch Carrier Com, Vienna, Austria

† Kapsch

Abstract: Often needed together, simulation and configuration play an important role in industry, from the early development stages as well as after deployment as part of system maintenance. Changes of a system’s structure or behavior over time are required because of changing requirements due to new customer needs. For example, the current worldwide willingness to adopt smart power grid technologies raises new challenges regarding the necessary adaptations in the structure and functionality of the existing mobile phone networks. In this chapter, we motivate the importance of both simulation and (re) configuration of mobile phone networks in the context of machine-to-machine communication, in order to deal with future markets of intelligent transportation systems and smart metering. We discuss our SIMOA approach for simulation and (re) configuration that is based on a system model and system requirements. The approach has the following advantages: it is flexible and adaptable to various systems and needs, it determines the system’s capabilities to handle certain requirements, and suggests system adaptations in cases where the requirements cannot be satisfied.

19.1 Introduction The machine-to-machine (M2M) communication market is expected to grow in the coming years and to become the largest customer of mobile phone network operators. The application scenarios of M2M communication are many faceted. Currently, the field of main application of M2M communication is smart metering, providing a direct link between power suppliers and electricity meters at home, and on tracking of vehicles and goods in the transportation industry. In this chapter, we focus on the first scenario (linking electricity meters at home). These smart metering application scenarios not only provide advantages for companies but also additional benefits for the customers. For example, smart metering solutions have the potential to avoid blackouts by limiting power consumption far before a blackout might occur. Another example is CO2 emission reduction in the electricity sector. More and more people produce and consume energy independently and feed unspent energy into the network. One hope in this context is to reach greater energy efficiency through short meter-reading intervals, as these allow the customers to control their energy consumption throughout the day. Energy network operators are then able to collect consumption data more frequently and to provide this data to end consumers in a transparent way. To complete all these tasks, intelligent communication solutions are needed, which are able to handle increased data volumes over the wireless Knowledge-Based Configuration. http://dx.doi.org/10.1016/B978-0-12-415817-7.00019-0 © 2014 Elsevier Inc. All rights reserved.

229

230

CHAPTER 19 Kapsch: Reconfiguration of Mobile Phone Networks

networks and especially over mobile GPRS/UMTS networks. Originally, communication infrastructures were not designed to fulfill the requirements of the mentioned M2M communication scenarios. The Kapsch Smart Energy Management System for metering and building automation offers a futureproof, open, and manufacturer-independent solution, which fits the needs of all the groups involved: from end consumers, building owners, and facility managers to network operators and energy suppliers. In this context, functionalities that support a detailed analysis of alternative smart metering scenarios are highly requested. In order to support such functionalities, simulations of various parts of a mobile network such as cell, backbone, and data storage have to be conducted. The major purpose of such a simulation is to check whether a network configuration can support a set of given user requirements. In order to simulate the dynamics of a mobile network, we treat each part of the mobile network, which is to be simulated, as a state machine with a predefined number of states. For example, in one particular state a component might be active whereas in another one this is not the case. Another example is a network configuration that may change from state to state in order to handle different communication requirements. If a simulation fails (the requirements cannot be fulfilled by the mobile network), a working reconfiguration of the given system has to be delivered. In particular, adding too many M2M devices to a cell configuration might lead to an unacceptable reduction of service availability, which can only be handled by changing the default value of the parameters in the cell (for instance, by increasing the number of serving frequencies) or by extending the communication network via adding new mobile phone cells.1 A cell configuration contains one base station, a number of metering devices, and a base load value. The major contributions of the chapter are the following: (1) we provide important insights into the principles of knowledge-based reconfiguration in the domain of M2M communication networks, and (2) we discuss major business cases that are related to the application of (re) configuration technologies in the context of mobile phone networks and M2M applications. The remainder of this chapter is organized as follows. In Section 19.2 we discuss in more detail the major requirements regarding the support of M2M communication scenarios. Afterward, we introduce an application scenario and give an overview of the SIMOA approach (Section 19.3). In Section 19.4 we discuss relevant business cases that are related to the application of SIMOA technologies. With Section 19.5 we conclude this chapter.

19.2 Domain Requirements Unlike today’s mobile networks, the future GPRS (General Packet Radio Service) networks used in Automatic Meter Management (AMM) communication have to support the following requirements: • • •

The GPRS networks have to be highly reliable and extensible. There must be a large IP address pool available. There is a required data amount specified for AMM communication.

1 When adding a new mobile phone cell to a network, in fact, a new base station is added to the system and the transfer data is redistributed to the cells.

19.2 Domain Requirements

•

231

The amount of data communicated via a GPRS network varies depending on the AMM readout frequency2 and the used communication protocols, such as the DLMS/COSEM or the IEC61107 protocol.

These requirements are of great importance for the configuration process. The user should be able to add a large number of devices in the network and the device type is either already defined in the knowledge base or a new type can be additionally defined. The last two requirements limit the space of possible reconfigurations by means of constraints stated over the data amount transferred in the network. Figure 19.1 illustrates a simplified cell from a smart grid,3 taking into consideration the GPRS data communication on the one side and the electric power transmission from the power generation station to smart meters on the other side (depicted in gray). Note that SIMOA simulation and (re) configuration focuses on GPRS data communication settings. As depicted in Figure 19.1, IP-enabled meters (Point-to-Point (P2P) individually addressable smart meters), which are connected directly to the WAN (Wide Area Network) using GPRS, communicate with the AMM application, without requiring data concentrators4 in the field. The meters connected to data concentrators are called PLC (Power Line Carrier) meters. The usage of P2P meters becomes inevitable when the connection distance between a meter and a data concentrator is too large (more than 300 meters). In the simulation process we have to take into account the following variants of M2M terminals in a specific cell: (1) only P2P meters, (2) only data concentrators with PLC meters, and (3) both P2P meters and data concentrators with PLC meters. In Figure 19.1, the Smart Grid (GPRS) cell comprises the following parts: •

•

•

Base Transceiver Station (BTS): Facilitates the wireless communication between user equipment (mobile phones, smart meters, etc.) and the network. The BTS has the equipment for encrypting and decrypting communications, spectrum filtering tools, antennas, and so on. Typically a BTS has several transceivers (TRXs) that allow it to serve several different frequencies and allocates a number of time slots for the M2M communication in the cell. P2P meters and Data Concentrators: These are described by configurable attributes that represent fixed or variable data amounts (derived from the chosen transfer protocols), network topology (determined by the distance between BTS and data concentrators/P2P meters), and in the case of data concentrators, the number of PCL meters connected to them. GPRS base load represented by the Mobile phone in Figure 19.1 and which represents all the nonsmart-metering traffic in the cell.

It is worth noting that the structure of mobile phone networks varies and that communication requirements depend on the M2M application scenario. A typical AMM scenario is, for instance, the transfer 2 The AMM readout frequency refers to the meter reading interval; i.e., for instance, an electricity meter can record the power consumption every 15 minutes. 3 A smart grid is a power transmission network, which makes use of supplier and consumer information and communication infrastructure to improve the overall network performance in terms of efficiency, reliability, and sustainability in an automated way. 4 A data concentrator is a device that is connected with several smart meters via a wire. In this case, all connected smart meters communicate to the AMM application over the data concentrator. Data concentrators are used, for example, in buildings with a large number of apartments where the costs for the additional wiring is low.

232

CHAPTER 19 Kapsch: Reconfiguration of Mobile Phone Networks

FIGURE 19.1 Schematic representation of a Smart Grid Cell containing a base transceiver station (BTS), one P2P smart meter, three PLC smart meters, connected to one Data concentrator, and a Mobile phone. The base station facilitates at cell level the data transfer from the P2P meter and data concentrator to the central meter management office, called AMM application.

of the daily load profiles5 from the meters to the AMM application within a defined time period. In this case, the traffic from the cell to the AMM application is investigated. Given, for instance, a GPRS cell with M2M communication capabilities comprising, among others, P2P meters, data concentrators, and mobile phones, we are interested in checking if the defined cell can handle the transfer of the load profiles or not. If the transfer is not possible (because there are insufficient time slots allocated for M2M communication in the cell or the transfer rate is too low due to the given channels encodings), a reconfiguration of the cell is required. This task comprises the identification of the inconsistent requirement(s) in the default configuration as, for instance, the assignment of an insufficient number of time slots for M2M communication, and changing the values of the corresponding attributes such that the new configuration is consistent. In another scenario, a large number of smart metering devices has to be simultaneously shut down by the power supply company in order to avoid a blackout. In this case, a pre-specified maximum delay (e.g., 2 minutes) between issuing the command and receiving it on side of the smart metering device must not be exceeded. 5 This

profile contains the amounts of power consumption recorded every 15 minutes.

19.3 SIMOA Approach

233

Hence, a solution for showing that a communication network fulfills the requirements of M2M application scenarios and taking counter measures in case of detected shortcomings has to be flexible and adaptable.

19.3 SIMOA Approach From the application domain we are able to derive the requirements for a tool that provides change operations for the given mobile network taking into account future usage scenarios. The future usage scenarios are determined by the communication needs of M2M applications (see, for example, the two scenarios discussed in the previous section). In the following, we discuss tool requirements with regard to the knowledge representation language, simulation features, reconfiguration, and optimization functionalities. •

•

•

•

6

Language. In order to support the discussed scenarios, we need information about the structure and behavior of mobile networks and related usage scenarios. Due to the huge variety of networks and usage scenarios, a modeling language has to be provided for formalizing the information. This language has to allow for stating the structure of a system and the behavior of its components. Temporal aspects, such as changes in network access over time, have to be captured as well. Moreover, in case of optimization requirements, the language has to provide means for stating optimality criteria. Simulation. The first step to evaluate whether an available mobile network is capable of handling all requests imposed by a future M2M application is to simulate the network behavior using the M2M communication requirements. Example requirements might be maximum delays of replies of remote machines on messages sent or the required amount of data to be sent at the same time. If the simulation returns that the network cannot handle certain requirements of the M2M application, someone is interested in finding a reconfiguration of the network that allows for fulfilling the requirements. The simulation itself should be based on the introduced modeling language. In the area of dynamic systems modeling and simulation, we mention Matlab/Simulink and Modelica.6 Although both of them are complex languages, capable of modeling a great variety of components, they are less appropriate for (re) configuration purposes, because they cannot handle underconstrained problems where a variety of solutions is possible. Reconfiguration. Changing an existing network for fulfilling communication scenarios imposed by M2M applications can be done on several levels. Certain parameters of mobile phone cells can be changed in order to provide more channels. New cells can be added to the network, thus changing the network topology. In our application all such possible changes should be reported. The same modeling language that is used for simulation should also be used for providing configuration information. Optimization. Since there is very likely more than one reconfiguration for handling future communication requirements, an optimal solution would be of great interest. Depending on who the user is, different optimality criteria are to be fulfilled. For instance, a mobile operator would prefer the reconfiguration that offers the best quality of service, whereas a customer would pick the solution with least costs for communication. Therefore, a requirement is that various optimality criteria can be specified and that it is possible to search for reconfigurations fulfilling the optimality criteria. www.mathworks.com, www.modelica.com.

234

CHAPTER 19 Kapsch: Reconfiguration of Mobile Phone Networks

To handle simulation, reconfiguration, and optimization based on the same underlying information we have adopted a model-based approach. In particular, we have designed a modeling language (SIMOL) that allows for specifying structure and behavior of systems as well as (re) configuration information and requirements. It is also necessary that the language can be used by non-AI experts. This is due to the fact that both the considered network as well as the M2M application requirements change over time and have to be adapted. The SIMOA approach is model-based and capable of fulfilling all the mentioned requirements. The approach is based on the SIMOL programming language (Nica and Wotawa, 2012), which is an objectoriented language with a Java-like syntax, and on the MINION constraint solver (Gent et al., 2006). As depicted in Figure 19.2, the resulting SIMOL tool architecture comprises three modules that are connected and interchange information: the SIMOL compiler, which maps the SIMOL program to a set of constraints (the MINION program) and also generates a symbol table that allows for mapping the variables used in the SIMOL program to the variables used in the constraint representation; the CSP solver, that computes a solution for the CSP problem; and the Mapping module, which takes the solutions coming from the constraint solver and changes the variable names to the names used in the original SIMOL program by using the previously generated symbol table. In this context, the reconfiguration core is represented by the CSP representation (MINION program) and the constraint solver; that is, the constraint solver is responsible for determining reconfigurations. The CSP solutions in Figure 19.2 are mapped to the actual reconfigurations, depicted by Solutions in Figure 19.2. A solution to a CSP problem is an assignment of values to variables such that no constraint is violated (see also Hotz et al., 20147 ). Due to this architecture, the SIMOA tool is general and can be used to solve various tasks. The only requirement is that the domain and the case-specific knowledge are specified using SIMOL. In Figure 19.3 we depict the UML diagram for a GPRS cell used in the SIMOL model and thus within our current implementation. As we can see, a cell owns one BTS component, a limited number of P2P Meter and Data Concentrator components, and a Base Load component. Moreover, the GPRS Cell has one attribute that refers to the possible GPRS/UMTS base load (gbase) the non-smart-meteringrelated data transfer, which is in fact defined in the value attribute of the Base Load component. A P2P Meter component type is described by the distance between the P2P meter and the BTS (mdist), the used codeset (codeset; the channel encoding that influences the amount of data to be transferred within one second), and by the various parameters corresponding to the protocol suites used to retrieve data from a smart device (dbr billing reads, iptlogin M2M gateway logins, etc.). Many of these attributes are to be found in the definition of the Data Concentrator type, but mostly with values depending on the number of PLC meters connected to the concentrator. Both PLC Meter and P2P Meter types are derived from the generic type Smart Meter. A BTS component has two attributes: the number of frequencies (fpc) and the number of time slots (availableTimeSlots), which the BTS allocates for M2M communication in a cell. Note that, unlike the other attributes depicted in Figure 19.3, these two can be automatically reconfigured in case of a failed simulation. In order to do that, two “fake” component types FPC (Frequencies Per Cell) and ATS (Available Time Slots) are introduced in the model (see Figure 19.3). They are “attributes-seen-as-components” types and, when linked to the actual attributes fpc and availableTimeSlots, they are able to reconfigure the given system.

7 Chapter

6.

19.3 SIMOA Approach

235

FIGURE 19.2 The SIMOA tool architecture.

For defining the model depicted in Figure 19.3, SIMOL makes use of component types, as illustrated in Figure 19.4. Each defined component possesses a set of attributes and introduces constraints in the system. Besides the constraints stated inside the constraints{…} block definition, also depicted as general constraints (see Figure 19.4, lines 30–36), SIMOL is able to capture the temporal aspects of the real system by means of state-specific constraints and transition constraints. While general constraints are satisfied in all the states, state-specific constraints are satisfied only in a certain state. The latter ones are provided in an additional observations file that contains at least the initial constraints (for the cell in the initial state). The transition constraints between two consecutive states appear in the transition{…} block and are implemented by means of the next operator (see Figure 19.4, lines 37–42). In our case, the GPRS cell model will be seen as a state machine with a predefined, bounded, number of states, where each state corresponds to different code-sets (attribute codeset) assigned to P2P Meter and Data Concentrator components. Thus, depending on the mdist attribute, which represents the distance between the BTS and the current meter m, the m.codeset value can be increased or decreased by following the transition constraints of the GPRS Cell component, as explained in Nica et al. (2012). Based on these transition constraints, the SIMOL compiler will generate for every state the new corresponding constraints.

236

CHAPTER 19 Kapsch: Reconfiguration of Mobile Phone Networks

P2P Meter 1 0..1000 codeset: [1..4]

1

dbr: [1..5] dlpr: 1 doa: [0..100] iptlogin: [1..10] iptconn: [1..10] iptwtg: [5’,10’,..30’]

GPRS Cell gbase: [10..50%]

1

1

1 Base Load value: int

1 BTS fpc: [1..10] ats: [1..4]

Smart Meter mdist: [1..3]

0..10 Data Concentrator mdist: [1..3] codeset: [1..4] dbr: [0..1500] dlpr: [0..300] dlpval: [0..3000] doa: [0..150000] iptlogin: [1..10] 1 iptconn: [1..10] iptwtg: [5’,10’,...30’]

The values for the distance base station - meter device “mdist” indicate: 1 closeby (distance