Pricing & Sign-up
|
Sign In
Home
|
Services
|
Upload
|
Forum
|
News
|
About
Arti®cial Intelligence in Engineering 15 (2001) 165±176
www.elsevier.com/locate/aieng
Conceptual modeling for con®guration of mass-customizable products
Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach*
È È Institut fur Wirtschaftsinformatik und Anwendungssysteme, Computer Science and Manufacturing Research Group, Universitat Klagenfurt, È Universitatsstraûe 65, A-9020 Klagenfurt, Austria
Abstract The development and maintenance of product con®guration systems is faced with increasing challenges caused by the growing complexity of the underlying knowledge bases. Effective knowledge acquisition is needed since the product and the corresponding con®guration system have to be developed in parallel. In this paper, we show how to employ a standard design language (Uni®ed Modeling Language, UML) for modeling con®guration knowledge bases. The two constituent parts of the con®guration model are the component model and a set of corresponding functional architectures de®ning which requirements can be imposed on the product. The conceptual con®guration model is automatically translated into an executable logic representation. Using this representation we show how to employ model-based diagnosis techniques for debugging faulty con®guration knowledge bases, detecting infeasible requirements, and for recon®guring old con®gurations. q 2001 Elsevier Science Ltd. All rights reserved.
Keywords: Product con®guration; Conceptual modeling; Knowledge acquisition; Diagnosis
1. Introduction Product con®guration systems play an important role in the support of the mass customization paradigm [20]. The increasing complexity and size of con®guration knowledge bases requires the provision of advanced methods supporting the con®gurator development process as well as the actual con®guration process. Informally, con®guration can be seen as a design activity, where the con®gured product is built from a prede®ned set of component types that can be parameterized and interconnected on pre-enumerated connection points. Additional constraints are used to restrict the number of legal product constellations. There exists a variety of application areas for product con®guration systems, e.g. in the computer industry (PC con®guration), telecommunication industry (con®guration of switching systems), or automotive industry (car sales con®guration). Fig. 1 shows the three main components of our proposed con®guration environment. Knowledge acquisition is done using con®guration domain speci®c modeling concepts represented as UML stereotypes [8]. UML [24] is a conceptual modeling language, which is widely applied in industrial software development processes. This notation is similar to Object Modeling Technique (OMT) diagrams
* Corresponding author. Tel: 143-463-2700-3757; fax: 143-463-27003799. E-mail address: dietmar@i®t.uni-klu.ac.at (D. Jannach).
[23] and is easy to understand and communicate to domain experts. The resulting models are automatically translated into a logical representation executable by a con®guration engine. After having designed and translated the con®guration model (knowledge acquisition), the resulting con®guration knowledge base has to be validated. We support this task in our framework using model-based diagnosis techniques: Given positive and negative con®guration examples (that can in turn be modeled on the conceptual level and transformed to a logical representation) we identify parts of the resulting knowledge base causing an unexpected behavior of the con®guration system. The outcome of this validation phase is a set of logical sentences from the generated knowledge base that has to be revised in order to correct the knowledge base. Note, that these results can be easily related to the pieces of knowledge from the (graphical) conceptual model. Therefore, the adaptation of the con®guration knowledge can be done again on the conceptual level. Once the knowledge base is validated and deployed in productive use, there may be situations where no solutions can be computed for a set of actual customer requirements. In such situations, our con®guration and diagnosis framework helps us to identify those parts of the user requirements prohibiting the successful con®guration of the product. Finally, given an already installed system and changed user requirements, the diagnosis techniques help us insofar that we are able to recon®gure the system such that the new customer requirements can be satis®ed.
0954-1810/01/$ - see front matter q 2001 Elsevier Science Ltd. All rights reserved. PII: S 0954-181 0(01)00016-4
166
A. Felfernig et al. / Arti®cial Intelligence in Engineering 15 (2001) 165±176
Fig. 1. Con®guration environment.
Note that we de®ned a clear correspondence between the conceptual model and the logical representation. Therefore, the inputs for the diagnostic reasoning can be mostly de®ned on the conceptual level, i.e. as UML diagrams containing con®gurations that are represented as instance diagrams. In addition, also the outcomes of the diagnostic reasoning can be traced back to those conceptual models. The paper is organized as follows. Based on the modeling concepts presented in [8] we give an example for the construction of a conceptual PC product model. We extend the set of modeling concepts by introducing the notion of functional architectures from Mittal and Frayman [18] in order to explicitly design functional structures [2], which are relevant for the speci®cation of (customer) requirements. In most cases customers are not interested in the detailed product topology but rather specify a set of functions the product must provide. In the line of [8] functional architectures are represented as UML stereotypes in the conceptual con®guration model in Section 2. Afterwards, we give a formal de®nition of a con®guration task based on the de®nitions of [12] which is the formal foundation for knowledge acquisition and the integration of the diagnosis techniques. The ®nal sections show how the different pieces of knowledge involved in the con®guration task (product model, user requirements, and con®guration results) can be analyzed using consistency-based diagnosis techniques. The paper ends with related work in the ®eld and conclusions.
requirements, technical restrictions, economic factors, and restrictions according to the production process. Fig. 2 shows how UML is embedded into a four-layer architecture. The UML metamodel, i.e. the modeling concepts provided in UML are de®ned in Meta Object Facility (MOF) [5], which provides the concepts for designing metamodels in general. Using the concepts provided by UML, concrete schemas such as the con®guration model in Fig. 3 can be designed. A concrete con®guration (result of the con®guration process) represents an instance of a schema. The basic means for de®ning additional modeling concepts inside UML is the introduction of a pro®le. A pro®le specializes the basic UML concepts (e.g. classes, associations, dependencies) for a speci®c domain by de®ning constraints on these concepts (de®nition of stereotypes). For the con®guration domain we de®ne special sets of classes (component types, resource types, function types,
2. Concepts for modeling con®guration knowledge bases For presentation purposes we introduce a simpli®ed (partial) UML model of a con®gurable personal computer (PC) as a working example. This model represents the generic product structure, i.e. all possible variants of the product. The set of possible products is restricted through a set of constraints which are related to (customer)
Fig. 2. Integration of UML in a metamodel architecture.
A. Felfernig et al. / Arti®cial Intelligence in Engineering 15 (2001) 165±176
167
Fig. 3. Conceptual product model.
and port types are specializations of the UML concept class), associations (incompatible, is_connected), and dependencies (requires, produces, consumes), which are useful for designing con®guration models. In order to make the resulting con®guration models executable, we propose a translation into the component port representation [7,12,18], which is well established for representing and solving con®guration problems. The semantics of the different modeling concepts are formally de®ned by the mapping of the graphical notation to logical sentences based on the component port model. In general, consistency-based tools based on this component port model can use the logic theory derived from the UML model although some transformation to the proprietary notation of a speci®c tool may have to be done. The following concepts are the basic parts of the ontology employed for designing con®guration models (compare, e.g. [25]). Note that we interpret ontologies in the sense of [3], i.e. ontologies are theories about the sorts of objects, properties of objects, and relations between objects that are possible in a speci®ed domain of knowledge. Component types. They represent parts the ®nal product can be built of. Component types (e.g. component type server-os in Fig. 3) are characterized by attributes that have a prede®ned domain of possible values. Function types. They are used to model the functional architecture of an artifact. Similar to component types they can be characterized by attributes (see Fig. 4).
Resources. Parts of a con®guration problem can be seen as a resource-balancing task, where some of the component (function) types produce some resource and others are consumers (e.g. the hd-capacity is a resource produced by hard-disks and consumed by software units). Generalization. Component (function) types with a similar structure are arranged in a generalization hierarchy (e.g. a server-os is either a server-os-1 or a server-os-2). Aggregation. Aggregations between components (functions) represented by part-of structures describe a range of how many subparts an aggregate can consist of (e.g. cpu is part of motherboard). Connections and ports. In addition to the amount and types of the different components also the product topology may be of interest in a ®nal con®guration, i.e. how the components are interconnected with each other (e.g. a pciconnector is connected to a pci-slot). Compatibility relations. Some types of components (functions) cannot be used together in the same ®nal con®guration, because they are incompatible (e.g. motherboard-2 is incompatible with cpu-586). In other cases, the existence of one component (function) requires the existence of another special type in the con®guration (e.g. server-os-2 requires motherboard-1). 2.1. Additional modeling concepts and constraints Constraints on the product model, which cannot be
