Computer-Aided Design 40 (2008) 863–878

Contents lists available at ScienceDirect

Computer-Aided Design

journal homepage: www.elsevier.com/locate/cad

Development of a product configuration system with anontology-based approachDong Yang ∗, Ming Dong, Rui MiaoDepartment of Industrial Engineering, School of Mechanical Engineering, Shanghai Jiao Tong University, 800 Dong Chuan Road, Shanghai 200240, China

a r t i c l e i n f o

Article history:Received 15 December 2007Accepted 20 May 2008

Keywords:Product configurationOntologyOWLSemantic web

a b s t r a c t

Product configuration is a crucial means to implement themass customization paradigm by assembling aset of customizable components to satisfy both customers’ needs and technical constraints. With the aimof enabling efficient and effective development of product configuration systemsby reusing configurationknowledge, an ontology-based approach to modeling product configuration knowledge is presented inthis paper. The ontology-based product configuration models are hierarchically organized. At the lowerlevel, a configuration meta-model is defined. Based on this meta-model, domain-specific configurationknowledge can be derived by reusing or inheriting the classes or relations in the meta-model.Configuration models are formalized using OWL (Ontology Web Language), an ontology representationlanguage developed by W3C. As a result, configuration models have well-defined semantics due tothe logic semantics of OWL, making it possible to automatically detect inconsistencies of configurationknowledge bases. Furthermore, configuration constraints are represented in SWRL, a rule language basedon OWL. Finally, actual configuration processes are carried out using JESS, a rule engine for the Javaplatform, by mapping OWL-based configuration facts and SWRL-based configuration constraints intoJESS facts and JESS rules, respectively. The proposed methodology is illustrated with an example forconfiguring the ranger drilling machine.

© 2008 Elsevier Ltd. All rights reserved.

1. Introduction

With the emerging paradigm of mass customization, productsare designed into customizable modules or parts to meet indi-vidual needs of customers [1,2]. With an increasing number ofmodules and parts in a customizable product, assembling thesemodules or parts into a legal constellation in a manual way be-comes impracticable [3]. To reduce lead-time and shorten productcycle, product configuration technologies are developed to auto-mate the processes of configuring a product [1,2]. A product con-figuration system is defined as one that is capable of automaticallyor interactively configuring a product to satisfy both customers’needs and technical constraints using product configuration tech-nologies. The application of product configuration systems facil-itates the sales-delivery process of products and avoids possibleerrors transferred between sale departments and engineering de-partments in manufacturing companies [4,46].

The study of effective product configuration technologies hasreceived much attention from the academic community and in-dustry over years [1–3]. Previous research effort focused mainlyon the actual configuration process for solving product config-uration problems, such as the rule-based approach [5] and the

∗ Corresponding author. Tel.: +86 02154744138; fax: +86 02134206675.E-mail address: dongyang@sjtu.edu.cn (D. Yang).

0010-4485/$ – see front matter© 2008 Elsevier Ltd. All rights reserved.doi:10.1016/j.cad.2008.05.004

CSP (Constraint Satisfaction Problem) approach [6,7]. Recently, at-tention has been directed towards the study of conceptual mod-eling of customizable products, namely, product configurationmodels [8,23,44]. This is due to well-defined conceptual mod-els being able to describe highly complex structures and con-straints of customizable products. As a result, product config-uration systems are able to deal with the problems of con-figuring complex products under mass customization. Further-more, the reusability of configuration models can effectivelyreduce the time of developing product configuration systems. On-tology, which is defined as the conceptualization of terms and re-lations in a domain, offers a means to structurally represent andreuse domain knowledge [9]. In this paper, we address the mod-eling of product configuration knowledge with an ontology-basedapproach in which structural knowledge is formalized in OWL(OntologyWeb Language) [10,11], an ontology representation lan-guage developed byWorldWideWeb Consortium (W3C), and con-straint knowledge in SWRL, (Semantic Web Rule Language) [12], arule language based on OWL. Through the transformation of con-figuration knowledge into JESS facts and JESS rules, actual config-uration processes are carried out with the support of JESS [13], arule engine for the Java platform.

The remainder of this paper is organized as follows. Thetechnical background is sketched in Section 2. Section 3 gives anoverview of related work. In Section 4, we present a four-layer

864 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

Fig. 1. The architecture of product configuration systems.

approach to modeling product configuration knowledge. Productconfiguration knowledge is then encoded using the ontologylanguage, namely OWL and the rule language, i.e. SWRL, whichis dealt with in Section 5. In Section 6, developing a productconfigurator based on the JESS rule engine is addressed. Finally,conclusions are drawn in Section 7.

2. Background

2.1. Product configuration background

Given a set of predefined components, the task of product con-figuration is to find a configuration solution satisfying individualneeds of customers without violating all constraints imposed oncomponents due to technical and economical factors [6]. Configu-ration models describing all legal combinations of components in-clude knowledge about the structure of products and knowledgeabout technical and economical constraints. Additionally, user re-quirements can be specified in the form of constraints, such as con-straints on properties of a component. Using a problem-solvingtechnology, configuration engines perform actual inference pro-cesses with both configuration models and user requirements asthe inputs and then generate a configuration as the output. A con-figuration (or configuration solution) consists of the componentindividuals, the assignment of values to properties of these indi-viduals and the connection relations among components such thatall constraints and customer requirements are satisfied. The archi-tecture of a product configuration system is shown in Fig. 1. Theproduct configuration problem can be formally described as fol-lows.

Definition 1. A configuration problem (CP) is formulated as:

CP := {C, P, Cr, R}

whereC — a set of components that may constitute a customizable

product;P — a set of properties of components;Cr — a set of constraints imposed on components due to

technical and economical factors.R— a set of customer requirements, which are usually specified

in the forms of constraints.

Definition 2. A configuration Solution (CS) or a configuration isdefined as:

CS := {I, V , S}

where

I — a set of individuals, which are instances of components.V — a set of values, which are assigned to properties of

individuals.S — a Boolean function, S : {Cr, R} −→ {T , F}. The assignment

of I and V makes the expressions Cr and R true.

Definition 3. A configuration engine (Ce) is a function that maps aconfiguration problem CP to a set of configuration solutions CS:

Ce : {CP} −→ {a finite set of CS}.

2.2. Ontology

An ontology is an explicit, formal specification of a sharedconceptualization of a domain of interest. The term is borrowedfrom philosophy, where an ontology is a systematic account ofexistence [9]. The ontology provides a shared understanding ofa domain of interest to support communication among humanbeings and applications. One main advantage of ontology is theability to support the sharing and reuse of formally representedknowledge by explicitly stating concepts, relations, and axioms ina domain.

Ontology has been widely applied in a variety of domains torepresent information or knowledge models owing to the fact thatits formal semantic can be unambiguously interpreted by humansand machines. Ontology can be formulated as below.

Definition 4. Ontology is defined as:

O := {I, C, R, A}

whereO — an ontology for a domain of interest;I — a set of individuals or objects in a domain;C — a set of concepts in a domain;R — a set of relations among concepts, relations and objects;A — a set of axioms holding among concepts, relations and

objects.

2.3. OWL

To encode configuration knowledge in a formal manner, itis requisite to employ an expressive knowledge representationlanguage. OWL is a new ontology language for the SemanticWeb, developed by the World Wide Web Consortium (W3C)Web Ontology Working Group [10,33]. OWL is primarily devisedto represent knowledge, namely objects and how objects areinterrelated, to be shared and exchanged without dispute as toprecise meaning. Absorbing the advantages of various knowledgerepresentation languages, the development of OWLwas influenced

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 865

Table 1OWL constructs

OWL Intuition

rdfs:subClassOf (A, B) Class A is a subclass of class B.rdfs:subPropertyOf (A, B) Property A is a sub-property of property B.P OWL: allValueFrom (C) All values of property P belong to class C .P OWL: someValueFrom (C) Some value of property P belongs to class C .P OWL: miniCardinality (n) The number of values that property P can take must be greater than or equal to n.P OWL: maxCardinality (n) The number of values that property P can take must not exceed n.P OWL: Cardinality (n) The number of values that property P takes is exactly n.

by Description Logics [34], RDFS (Resource Description FrameworkSchema) [51] and Frame paradigms. The semantics of OWL [35] arebased on Description Logics whose advantage is that a knowledgebase can be automatically checked against subsumption of classes,inconsistency of concepts and entailment relationships. OWLalso offers surface syntax in both RDF (Resource DescriptionFramework) /XML and frame-like formats [35], making OWL easilyreadable and understandable even for non-experts. Regardinglanguage constructors and expressive power of languages, OWL is amajor extension over RDFS. Table 1 givesmain language constructsin OWL and their corresponding intuitive meaning.

3. Literature review

In this section, we mainly address related work in productconfiguration and ontology application in manufacturing. Duringrecent years, much research effort has been devoted to developingproduct configuration systems. Various techniques have beensuggested to solve product configuration problems, including theGA (Genetic algorithm)-based approach, case-based reasoning(CBR) method, rule-based approach, CSP-based technique, etc. Onthe other hand, ontology has been applied by many researchersto model engineering and design-related knowledge to facilitateknowledge reuse and information sharing among applications. Themain research work in both product configuration and ontologyapplication is summarized below.

3.1. Related work in product configuration

Genetic algorithms have been used in the literature to solve theproduct configuration problem [14–17]. Hong et al. [14] addressedthe problem of optimal product configuration under the One-of-Kind production (OKP) paradigm. Variations for customizableproducts and parameters in the OKP product family were modeledwith AND–OR trees and parameters of nodes in this tree. Theyemployed the genetic algorithm as the solving mechanism toobtain optimal configuration, taking customer requirements ondifferent aspects such as performance and cost into consideration.Zhou et al. [15] adopted the AND–OR graph to represent theconfiguration spaces of a customized product. The optimization ofproduct configuration was done by means of a genetic algorithm.The objective function of optimization considered both customerpreferences on product attributes, which were measured usingutility function, and costs of a product. Different from the workin [14], a distinguishing characteristic in their research is thatconfiguration constraints, such as inclusive relations and exclusiverelations, are considered in the genetic algorithm for solvingand optimizing product configuration problems. Similar work onthe use of genetic algorithms for solving product configurationproblems was also reported by Li et al. [16] and Yeh et al. [17].Nevertheless, the GA-based approach for product configurationis only suitable for the configuration problems where only a fewconfiguration constraints exist in configuration models and thusnumerous feasible solutions can be obtained. Obviously, it is not anideal candidate for configuration problems that are characterized

by complex structures and a number of strict constraints imposedon components.

A different viewpoint on product configuration is that theproduct configuration problem can be seen as one of case-basedreasoning (CBR) [18,19]. To configure a new customer order,similar previous cases are retrieved and the one with best degreeof similarity is recommended. For instance, Tseng et al. [18]adopted the CBR to perform actual product configuration, aimingto reuse previous successful reasoning case. Similar work thatused the CBR for product configuration was also reported byLee and Lee [19]. However, CBR-based method is only usefulwhen knowledge is incomplete. Therefore, the reuse of productstructure knowledge and constraints is not supported in the CBR-based product configuration. As a consequence, the CBR-basedconfiguration is limited to some special occasions.

The very earliest product configurator, namely R1 system (latercalled XCON), used a rule-based reasoning approach for productconfiguration [5]. However, the weakness of the rule-basedapproach lies in the problem with maintaining rule bases becauseboth configuration knowledge (including product structures andconstraints) and policy knowledge (namely that concerning howto solve configurations) are interweaved in rules [1].

Mittal and Frayman [6] viewed product configuration asthe CSP problem (Constraint Satisfaction Problem) where bothports and components are treated as variables with finitedomains. Therefore, the aim of product configuration is to finda set of assignment of values to variables without violatingany constraint. Various CSP solving algorithms [20], such asbacktracking and consistency checking, can be employed toperform configuring processes to reduce search spaces and thusimprove search efficiencies. Fohn et al. [21] suggested the CSP-based method to solve automatic configuration problem forinteractively configuring personal computer systems. Xie et al. [22]further extended the CSP-based approach to consider engineeringproduct configuration problemwhere constraints typically containmathematical formulae and computable procedures. Nevertheless,a classical CSP-based configuration method cannot handle thesituation where constraints could dynamically be joined inconstraint networks, depending on some decision, such as user’schoice. To consider this problem, the Dynamic CSP (DynamicConstraint Satisfaction Problem) approach was presented as anextension to traditional CSP, introducing active variables and activeconstraints to specify condition underwhich a variablemay ormaynot be actively considered as a part of a final solution [7]. Althoughthe CSP-based approach and its variants have been widely appliedin solving product configuration problems, they cannot representcomplex structures of customized products, such as whole-part relations between components, abstract components, andadvanced constraints (such as resource constraints) because aproduct in the CSP-based approach is simply represented as thatconsisting of components and the connections between their ports.As a result, the CSP-based approach has difficulties in dealing withconfiguring highly complex and customizable products.

Tomodel customized and complex products, Felfernig et al. [23]adopted UML (Unified Modeling Language) [47], an industrialstandard for object-oriented notations, to model the product

866 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

configuration knowledge. High-level modeling concepts includingpart-of, subclass-of, ports and resources were offered in theirresearch using UML stereotypes. The main benefit for theirapproach is that UML has a graphical means, enabling it to bemoreconvenient to communicate among experts, modelers and users.Nevertheless, the UML-based configuration models are requiredto be transformed to range-restricted first-order logics to giveconfiguration models rigorous semantics since UML itself doesnot have formal semantics that are clearly defined. Configuringprocesses were carried out using JConfigurator, a commercialsolver developed by ILOG Corporation that implemented theCSP-based algorithm. Similarly, Ong et al. [24] presented anobject-oriented modeling method to explicitly and hierarchicallyrepresent configuration domain knowledge using special O–Onotations. An actual configuration process for configuring acustomizable bicycle was done through the use of CSP-basedinference approach.

By contrast, our work is to take a step forward in rep-resenting highly complex and customizable products using anontology-based knowledge representation approach. In addition todescribing structural knowledge like the O–O approach, theontology-based approach for product configuration knowledgeoffers expressivemodeling primitives, such as constraints on cardi-nalities of properties. Furthermore, the ontology-based configura-tion models are of rigorous semantics, making it possible to be in-terpretable bymachines, be shared and reused across applications.In next sub-section, the application of ontology in manufacturingor engineering fields is reviewed.

3.2. Related work in Ontologies for manufacturing domains

As an explicit specification of a conceptualization, ontologyplays a significant role in these aspects: sharing information,integrating different applications, implementing interoperabilityand reusing knowledge. Although research about ontology hasits root in the computer domain, ontology has been applied ina variety of domains due to the advantages mentioned above.Naturally, ontology can be utilized in the manufacturing domain.As a matter of fact, some research effort has been attempted toemploy ontology-based techniques in manufacturing or in theproduction domain for integrating engineering applications.

Kim et al. [25] addressed the ontology-based assembly designto support collaborative product development such that designintent could be well understood by other designers, and the ap-plications could reason about assembly knowledge without anysemantic ambiguity. An assembly design ontology, called AsD,defining shared conceptualization of assembly design modeling,was developed in their research to make assembly knowledgeaccurate and machine-interpretable. Yang and Zhang [26] sug-gested that semantic interoperability in building design, whichtypically involved multi-disciplinary project teams at distributedsites, could be tackled by building design domain ontology defin-ing concepts, terms and relations common to project teams. Cio-coiu et al. [27] discussed the use of ontology as the techniqueto integrate different engineering applications, for example, be-tween CAD and manufacturability analysis, by defining sharedcommon ontologies or using ontology as an interlingua. As a re-sult, semantic clashes and ambiguity between terms defined indifferent engineering applications could be effectively avoided.Saeema Ahmed et al. [28] developed an ontology for engineer-ing design for knowledge sharing among engineers to assist en-gineers in indexing, searching, and retrieving design knowledge.Paul Witherell et al. [29] recognized that current design and op-timization in engineering domain were hindered by an immenseamount of inconsistent terms and vocabularies that existed invarious specialized or similar optimization packages detailed for

particular functions. The problems with information sharing andinteroperability arise when the same engineering optimizationproblem is performed by different optimization tools with theirown advantages in some aspects. To tackle this problem, an en-gineering optimization ontology dubbed ONTOP was developed tofacilitate both sharing and exchanging of optimization knowledgein the engineering design domain. Two engineering case studies,one of which was the optimization of structural beam elements,were presented to demonstrate the ability of ontology as a meansof sharing optimization knowledge among different optimizationtools. Port is an important concept in conceptual design ofmechan-ical systems, describing how the sub-systems are interconnectedand interacted through exchange of signal, energy andmaterial. Torepresent ports in a formal andunambiguousway, Vei-Chung Liangand Paredis [30] defined port ontology to accommodate the differ-ences in vocabularies and approaches across different disciplinesand perspectives. As a result, engineers and computer aided de-sign applications could reason about component connections andinteractions in a system configuration. Cho et al. [31] realized thatseamless integration of current digital part libraries was impededby semantic heterogeneity. They developedmeta-ontology for partlibraries to provide an integrated view of multiple part libraries.Based on meta-ontology, domain-specific part ontologies weredescribed.

3.3. Related work in Ontologies for product configuration

Product configuration is characterized by close interactionamong agents such as customers, sale engineers and technicians.Since ontology can facilitate cooperation among participants bysharing common terminologies and vocabularies in a domain,research regarding the application of ontology to the product con-figuration domain has attracted a lot of attention in both indus-try and academia recently. Zhang et al. [43] defined ontologies forconfiguration problems, which contained essential concepts suchas component, resource, port, function, etc. Nevertheless, theseontologies are represented in an informal approach, namely, theobject-oriented method. Despite the advantage of reusing models,the object-oriented approach cannot characterize the formal se-mantics of configuration models. Consequently, the ontologies de-fined in O–O languages suffer from an informal description, whichwill lead to potential problems with cooperation among agents.Furthermore, making inferences on informal ontologies is impos-sible due to the lack of rigorous semantics. Soininen et al. [44]presented a general ontology of configuration, which integratedthe concepts port, function, constraint, attribute, etc. To some ex-tent, the general ontology defined by Soininen, T is similar tothe meta-ontology presented in this paper although there existminor differences in handling the abstraction of assemblies andconstraints. However, both approaches differ in formal represen-tation of configuration ontologies. Encoding ontologies in a rigor-ous way is crucial to constructing knowledge bases and makinginference on knowledge bases. For ontology codification, thereexist two mainstream approaches for formalization of ontolo-gies [45]. One is based on first-order logics (such as Ontolingua [9])and the other is to employ a description-logic approach (such asOWL). In Soininen et al.’s study, configuration ontologies were for-malized in Ontolingua, a knowledge representation language com-bining first order logic (KIF [52]) and frame paradigms. AlthoughOntolingua is the most expressive of all the languages that havebeen used to represent ontologies [53], its high expressiveness re-sults in difficulties in building a reasoningmechanism for checkingthe consistencies of knowledge bases. Hence, no reasoning supportis provided with the language [53]. By comparison, the ontology inour approach is formalized in OWL, a new ontology for the Seman-tic Web. OWL is based on DL (Description Logic) that makes mod-els tractable with regards to tasks such as the checking of concept

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 867

Fig. 2. Four-layer modeling architecture.

consistencies [53]. Nowadays, an increasing number of reasoningtools for OWL such as RacerPro [54] is available for checking con-sistencies of knowledge bases. Consequently, configuration knowl-edge bases formalized in OWL can be efficiently maintained due tothe support of reasoning tools. Altuna et al. [42] developed Con-figuration Ontology in the OBELIX project to support collaborativeconfiguration of products and services. Although there are similar-ities between the Configuration Ontology and the meta-ontologydefined in our research, both approaches differ in the abstractionof the port, resource and constraint concepts. For example, in ourapproach, the port is only used to represent a physical connectionbetween two components. However, the port concept is furtherrefined as the InputPort and OutPort in OBELIX Configuration On-tology. In the Configuration Ontology, resource is associated withthe port by the relation belongToPort while in our approach, a re-source is directly related to a component by the relations supply-resource and consume-resource between the concept Componentand Resource. Furthermore, the representation of constraints inthe OBELIX Configuration Ontology is rather simpler. Typical con-straints are those restricting the number of components or ser-vices, the parameters of components or services. In contrast, manycomplex constraints such as the require constraint, incompatibil-ity constraint, resource constraint and connection constraint areconsidered in our ontology. The differences between the presentedmeta-ontology and Configuration Ontology are due to the fact thatthe research aim in our project is to configure a single physicalproduct (such as amechanical product) by assembling componentswithin the product while the aim of the OBELIX project is to con-figure multi-products or services where constraints are relativelysimple and ports used to receive or offer services are much morecomplicated. Finally, encoding configuration ontologies is differentin both approaches. In the OBELIX project, ontologies are encodedin RDF. The representation of complex constraints such as chainingof properties is not supported in RDF. In contrast, the configura-tion ontologies in our approach are encoded in OWL that is muchexpressive than RDF. Moreover, complex configuration constraintscan well be described in our approach using SWRL.

4. The approach tomodeling product configuration knowledge

4.1. Four-layer modeling architecture

To encourage reuse of configuration models and flexibility inrepresenting knowledge, the presented modeling approach forproduct configuration knowledge follows four-layer architectures,as shown in Fig. 2. At the lowest layer, namely the representationlayer, the aim is to choose an ontology representation language toformalize configurationmodels. Typical knowledge representationlanguages contains OWL, KIF (Knowledge Interchange Format),UML meta-model, etc. The second layer from bottom to up isthe meta-model layer in which the configuration meta-ontologyis defined. This meta-ontology identifies general terminologies,

vocabularies and relationships that are common to a varietyof configuration domains. Consequently, configuration meta-ontology serves as a common semantic framework on whichconfigurationmodels for specific configuration domain can be builtthrough the inheritance or reuse of concepts and relations in themeta-model. This meta-model can be reused independently ofconcrete configuration domains. The product configurationmodelsfor specific configuration domains such as computer configurationand automobile configuration lie in the third layer, i.e. the modellayer. The top layer is the instance layer, denoting a concreteconfiguration result that conforms to configuration modelswithout violating any constraint. By using four-layer architectures,knowledge share is ensured due to the fact that meta-ontologycan be reused in various configuration domains. Additionally,the difficulties in modeling product configuration knowledge canbe dramatically reduced by constructing configuration modelsbased on existing configuration knowledge instead of starting forscratch. Further, the presented approach is flexible in choosingthe knowledge representation language to formalize productconfiguration models.

4.2. Meta-ontology for product configuration

As described above, meta-ontology for product configurationserves as the meta-model defining general and common termsand relations common to the configuration domain and thus isindependent of product-specific configuration domains such asautomobile and computer configurations. Meta-ontology includesthe identified concepts (or classes) and relations among them.Meta-ontology is developed in our research by using the skeletalmethodology presented by Uschold and King [32]. The method-ology includes the following four stages: identify the purpose ofthe ontology, build the ontology, evaluate it and document it. Thebuilding activity is decomposed into three activities of capturingthe ontology, coding it and integrating other ontologies inside thecurrent one. This following section describes identified conceptsand relations within the meta-ontology model.

4.2.1. Concepts in this meta-ontology for product configurationThe definitions, possible terms, and concepts within the

product configuration domain are investigated by authors. Theterms investigated include Function, Component, Sub-assembly,Part, Port, Resource, Attribute, Constraint, Product, Value, etc.

An ontology consists of classes, properties and axioms. A classdefines a concept while a property between two classes indicatesa relation holding between two instances of these two classes.Based on the terms investigated, classes and relations among themare extracted. Fig. 3 shows the hierarchy of classes in the meta-ontology for product configuration. Main classes in this meta-ontology are explicated below.

Class component is a constituent element, of which acustomized product is composed, to provide some functions ofa product. A component itself may be an sub-assembly of othercomponents, or an atomic part that cannot be further decomposed.

Class product represents a configurable product consisting ofsub-assemblies or parts.

Class sub_assembly denotes a physical aggregation of otherparts. For example, a motherboard in a personal computer is a sub-assembly consisting of CPUs, chips and slots, etc.

Class part is a component that cannot be further divided intoother parts or sub-assemblies.

Class function represents what customers expect a product toprovide. Functions and components can be associated with N: M(i.e. many-to-many) relationship. This means that a function maybe implemented by several components, and in turn, a componentmay provide several functions.

868 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

Fig. 3. Classes.

Fig. 4. Relations.

Class port is a physical place of a component through whichthe component can be connected to other parts. Therefore, theport concept describes how components in a configuration areinterconnected.

Class resource represents what a component in a configurationcould supply or consume. To take an example, in a personalcomputer configuration, hard disks supply the disk capacitieswhereas operation systems consume the disk capacities.

Class attribute describes the parametric properties of acomponent,which can bemeasured using someunits. For instance,an engine has the weight as its attribute. In some literature, theattribute is also called the parameter.

Class datatype whose instance is a concrete value to which anattribute or resource of a component refers. The DataType classmay be integer, or float type, or enumeration type.

Class constraint restricts legal combination of components in aconfiguration. Constraints are imposed owing to technical and eco-nomical factors. Constraints can be classified into intra-constraints,which place restrictions on a component’s characteristics, andinter-constraints, which impose restrictions between or amongseveral components.

Class intra_constraint indicates restrictions on a componentand is further classified into cardinality constraint, essentialconstraint and optional constraint.

Class cardi_constraint restricts the number of a componentsoccurring in a configuration. For instance, a cardinality constraintmay say that the number of 486-CPUs in a computer should be lessthan two.

Class essen_constraint indicates an essential restriction,namely a component must be in a configuration. To take an ex-ample, it is essential that engine A must be in a car configuration.

Class opt_constraint specifies that a component is optional in aconfiguration. For instance, a DVD player is optional in a computerconfiguration.

Class inter_constraint indicates the constraints imposedbetween or among several components in a configuration. It isfurther classified into resource constraint, port constraint, requireconstraint and incompatibility constraint.

Class req_constraint specifies such a relationship between twotypes of component, namely, one type of component that is in aconfiguration requires another type of component to be involved inthis configuration. For instance, the existence of CPU-486 requiresthe existence of Intel_Motherboard in a configuration.

Class incom_constraint states that some types of componentcannot be used together in the same final configuration, becausethey are incompatible. To take an example, the motherboard-AMDis incompatible with the CPU-586.

Class port_constraint stipulates which types of componentsshould be connected through their own ports. Consequently,the port constraint depicts the connection relationships betweentwo components in a configuration. For examples, one portconstraint may indicate that SCSI-Controller should be connectedwith motherboard_1 through their corresponding ports, i.e. PCI-connector and PCI-slot.

Class res_constraint specifies that for a legal configuration, thetotal amount of resources consumed by components should be lessthan that of resources supplied by components. For instance, in acomputer configuration, the total capacity of disk space consumedby various software installed in a computer should be less than thatprovided by hard disks in the computer.

Class cust_requirement represents customer’s requirementon customizable products. These requirements typically mayplace restrictions on either function of products, or structures ofproducts. In the product configuration, customer’s requirementsare often described in the form of constraints.

4.2.2. Relations in the meta-ontology for product configurationIn addition to the identified classes in the meta-ontology for

product configuration, some relations among these classes aredefined, as shown in Fig. 4. The relations has_attribute, has_port,has_function, etc. are object properties, which means that rangesof these relation belong to classes. In contrast, has_value is a dataproperty, indicating that its range is integer, float, etc.

The hasAttribute defined between Component and Attributeindicates that a component may have attributes. The hasPort thatexists between component and port means that a component

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 869

Fig. 5. Meta-ontology for product configuration.

Fig. 6. The ranger drilling machine [4].

may have ports. The consumeResource and supplyResource betweencomponent and resource represent that a component can consumeresources or provide resources, respectively. A component mayhave some constraints attached to it, which is indicated by therelationship hasConstraint between component and constraint.Since resources can be measured in some units, the resource hasan attribute, which is represented by the relation hasAttributebetween Resource and Attribute. Fig. 5 depicts all identified classesand the relations among them in the meta-ontology for productconfiguration.

5. Product configuration modeling using ontology language

Based on the meta-ontology described in Section 4, a product-specific configuration model can be derived through reusing orinheriting concepts or relations in the meta-ontology model.

To illustrate the presented approach to modeling configurationknowledge using ontology, a configuration case from [4] withslight modification is employed in our research.

5.1. An illustrative example for product configuration

We use a configurable ranger drilling machine, which is shownin Fig. 6, as an example of product configuration. This rangerdrilling machine consists of a body, a cabin, a tracked crawlerbase, a power unit, a boom and drilling equipment. The body isdivided into power unit, cabin, fuel oil tank, hydraulic oil tank.Fig. 7 shows the configurationmodel of configurable ranger drillingmachine graphically. For the sake of simplicity, only the parts thatare important from the configuration point of view are presentedin this example and some components such as reservoir controland device instruments in this machine are omitted. Also, someimaginary configuration constraints are added in this example inorder to better verify the effectiveness of the presented approach.

As shown in Fig. 7, the drilling boom assembly is composed of aboom feeder, one or two rock drills and an optional suction head.The cardinality [1..2] between the drilling boom assembly and therock drillmeans that for a legal configuration, there are one or tworock drills. As an abstract component, the rock drill classified intoHL 500 and HL 600_700. The latter is further subtyped into HL 600and HL 700.

Constraints exist in the configuration model. For example, theincompatibility constraint C1 indicates that the type high capacitypump and the type three-edge track cannot be used together at thesame configuration. The tank USA requires the existence of a three-edge tack, as indicated by the require constraint C2. The resourceconstraint C8 means that the total amount of power consumed byHL 500, HL 600 and HL 700 should be less than that supplied byEngine R, S and W . Moreover, the rock drill should be connectedwith the DA (drill attachment) through their respective ports, suchas Ldp and Lba. The port constraint C6 indicates that the Hdp portof HDAmust be connected with the Hba port of HL 600_700, whichmay be HL 600 or HL 700. The port constraint C7 signifies thatthe Ldp port of the component LDA should be connected with theLbaport of the component type HL 500.

870 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

Fig. 7. A customizable ranger drilling machine.

Additionally, customers may specify their requirements ondesired products in terms of product functions or in termsof constraints such as require constraints and incompatibilityconstraints. For instance, the customer requirement R1,which is anrequirement on functions of this product, means that the desireddrilling diameter should be between 72 mm and 92 mm. This inturn requires the selection ofHL600 according to themapping fromfunction to component. Other customer requirements R2–R4 arespecified by directly imposing constraints on components in theform of require constraints and incompatibility constraints.

If all technical constraints C1–C10 and customer requirementsR1–R4 are considered, a configuration solution for this rangerdrilling machine is:

?High_capacity_pump = iHigh_capacity_pump (an individual ofHigh_capaicty_pump)

?Normal_pump=null?Engine_W=iEngine_W (an individual of Engine_W)?Engine_R=iEngine_R; (an individual of Engine_R)?Engine_S=null;?Tank_EURO=iTank_EURO; (an individual of Tank_EURO)?Tank_AUS= null?Tank_USA=Null?LDA=null;?HDA=iHDA; (an individual of HDA)?Ldp=null;?Hdp=iHdp; (an individual of Hdp)?HL 600=iHL 600; (an individual of HL 600)

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 871

Fig. 8. Relationship between meta-onology, models and individuals.

?HL 500=null;?HL 700=null;?Hba=iHba_1; (an individual of Hba)?Lba=null;?Normal_track = iNormal_track; (an individual ofNormal_track)iThree_edge_track=null;?AC5=iAC5; (an individual of AC5)?AC6_7=null;?Hose_reel=null;?Suction_head=null;has_dp_port(iHDA, iHdp);has_ba_port(iHL 600, iHba_1);is_connected(iHdp, iHba_1);. . . . . . . . . . . . .Here, ?Normal_pump is a variable representing an instance

of the component type Normal_pump. If ?Normal_pump is equalto null, this indicates that the corresponding component Nor-mal_pump does not be included in the configuration solution. It canbe checked that this solution satisfies all constraints and customerrequirements.

5.2. Product configuration modeling for case study

Modeling configuration knowledge for a configurable rangerdrillingmachine is carried out according to the four-layermodelingarchitecture mentioned in Section 4. Product-specific configura-tion knowledge consisting of domain classes and relations amongthem is derived through the inheritance or reuse of the classesor relations in the meta-ontology model. For example, the con-cept Engine_S is the subclass of the class Part in the meta-ontologywhereas the domain concept Boom_feeder is the subclass of theSub-assembly. The Resource and Port classes in the meta-ontologycan be refined to the Power and Lba subclass in the configurationmodel, respectively. Furthermore, the relations in the meta-modelcan be subclassed to specific sub-properties in the domain model.To take an example, has_part relation in the meta-model is re-fined to the has_engine relation with the Power_unit_assembly asits domain and the Engine_S as its range. For the same reason, the

supply_power relation that exists between the Engine_S and thePower is the sub-property of the has_resource in the meta-model.

The domain classes and relations in the configuration modelcan have their individual (instances) thatmay form a configurationsolution. To take an example, iUSA_lang is an individual of theLanguage class in the configuration model. iPower_135 is aninstance of the Power class, representing that the amount of poweris equal to 135 kW. Fig. 8 depicts the interdependencies amongthese three-levels in graphical way.

5.3. Modeling configuration model using Protégé

Themodeling process for configuration knowledge is facilitatedusing Protégé tool [36], developed by Stanford University, whichprovides an environment of creating, editing and saving ontologiesin a visual way. Protégé also offers the support of modelingontologies in the OWL ontology language. Obviously, it is veryconvenient to create the sub-classes of a class and to specifyrestrictions on class properties using the protégé. For instance,the Drill_boom_assembly, a child class of the sub_assembly, hasone or two drills, exactly one feeder and zero or one suctionhead, which are specified using specific modeling constructs suchas min, max, exactly in the Protégé-OWL. Fig. 9 shows classhierarchies modeled for the ranger drill machine, which arecreated using OWL-Viz plug-in [37] in the Protégé. Relationshipsare represented as properties in OWL, which are further splitinto object properties and data properties. The object propertiesrefer to these properties with classes as both domains and rangeswhereas the data properties have only data types such as integer,string or OWL: anything as ranges. Individuals that may constitutea configuration solution are instances of classes. For example,iBoom_feeder (here the prefix ‘‘i’’ means individuals) is an instanceof the class Boom_feeder.

5.4. Encoding product configuration knowledge

Product configuration knowledge is encoded in OWL such thatconfiguration knowledge can be understandable to both machines

872 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

Fig. 9. Class hierarchies.

and human beings. More importantly, as a formal languagewith description logic-based semantics, OWL enables automaticreasoning about inconsistencies of concepts. OWL providesRDF/XML syntax to represent ontology-based domain knowledge.For example, the encoding of the class Drill_boom_assembly inOWL RDF/XML is shown in Fig. 10. The subClassOf constructindicates that Drilling boom assembly is a sub_assembly. The OWL:miniCardinality (OWL:maxCardinality) restricted on the has_drillobject property means that a drilling boom assembly at least (atmost) has one (two) drills.

Moreover, both object properties and data properties are alsoencoded in OWL RDF/XML syntax. Fig. 11 shows the part ofRDF/XML files that encodes the object properties has_engine,

consume_power as well as the data property is_of_value. TheOWL:objectProperty is used to indicate that the representedproperty is an object property. The rdfs:domain (rdfs:range)construct refers to the domain (range) of a object property. Forexample, has_engine has Power_unit_assembly and Engine as itsdomain and range, respectively. The rdfs: subProperty implies thatthe represented property is a sub-property of some property. Totake an example, has_engine is a sub-property of the has_partproperty, which is indicated using rdfs: subPropertyOf. Fig. 12shows the encoding of individuals of classes in OWL RDF/XMLsyntax. An individual of the class Engine_S, namely iEngine-S, thatsupplies the 135 kW power is described in this figure.

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 873

Fig. 10. Encoding classes in OWL RDF/XML.

Fig. 11. Encoding classes in OWL RDF/XML.

874 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

5.5. Modeling and encoding constraint knowledge

In OWL, it is convenient to describe the intra-constraints,namely the constraints restricted only on a component, suchas cardinality constraints and optional constraints, throughthe use of using OWL constructs (such as OWL:minCardinality,OWL:maxCardinality and OWL:cardinality). For instance, the es-sential constraint can be represented by specifying that corre-sponding value of OWL:cardinality equals to one. Similarly, theoptional constraint can be described by limiting the value ofOWL:minCardinality to zero. However, OWL cannot express inter-constraints, i.e. the constraints restricted among or between com-ponents, which typically occur in the form of rule types. This isbecause OWL cannot describe the property chaining [38]. For ex-ample, it is impossible to capture relationships between a com-posite property (such as the composition of the ‘‘parent’’ and‘‘brother’’) and another (possibly composite) property (such as the‘‘uncle’’ property). To represent rule knowledge, W3C has devel-oped SWRL rule language [12], which is tightly integrated withOWL since the predicates in SWRL rulesmay be OWL-based classesor properties.

SWRL combines the OWL DL and OWL Lite sublanguages withtheUnary/BinaryDatalog RuleML sublanguages and has the advan-tages of close association with OWL. It mainly deals with Horn-likerules that are of the form of an implication between an antecedent(body) and consequent (head), meaning that the conditions speci-fied in the consequent must hold whenever the conditions spec-ified in the antecedent are satisfied. Both the antecedent andconsequent consist of zero ormore atoms. Atoms are the form C(x),P(x, y), sameAs (x,y) or differentFrom (x,y), where C is an OWL de-scription, P is an OWL property, x and y are variables, OWL individ-uals or OWL data values. In this syntax, a rule has the form:

Antecedent −→ consequent

where both antecedent and consequent are conjunctions of atoms.Variables are indicated using the standard convention of prefixingthem with a question mark (e.g., ?x).

Based on the classes and properties that have been modeled inProtégé-OWL, the configuration constraints in the case study areexpressed in SWRL. For example, the incompatibility constraint C1can be represented in SWRL as follows:C1 (Incompatibility constraint):

High capacity pump is incompatible with Three-edge track.SWRL rule:Ranger_drilling_machine(?x) ∧ has_fuel_tank(?x, ?y)∧ Fuel_tank(?y) ∧ has_fuel_pump(?y ?z)∧ High_capacity_pump(?z)∧ has_crawler(?x, ?a) ∧ Crawler_assembly(?a)∧ has_drive(?a, ?b) ∧ Caterpillar_drive(?b)∧ has_track(?b, ?c) ∧ Three_edge_track(?c) −→

Here the head of this rule is void, representing the fact, namelythat both the component type High capacity pump and the com-ponent type three-edge track exist in the same configuration, can-not hold. The predicates such as Fuel_tank and has_drive are theconfiguration knowledge that has been modeled in Protégé-OWL.The require constraint C2 is described in SWRL as below.C2 (Require constraints):

The component typeTank_USA requires the existenceof the Three_edge_track in a configuration.SWRL rule:Ranger_drilling_machine(?x) ∧ has_power_unit(?x, ?y)∧ Power_unit_assembly(?y)∧ has_tank(?y, ?z) ∧ Tank_USA(?z) ∧ has_crawler(?x, ?a)∧ Crawler_assembly(?a) ∧ has_drive(?a, ?b)∧ Caterpillar_drive(?b)∧ has_track(?b, ?c) −→ Three_edge_track(?c)

The representation of the port constraints is similar to that of re-quire constraints except that the relation is_connected needs to besatisfied between the corresponding ports of two connected com-ponents. For instance, the port constraint C6 is described as below.C6 (Require constraints) :The Hdp port of the component type HDAmust be connectedwith the Hba port of the component typeHL 600 or HL 700 ina configuration.SWRL rule:Ranger_drilling_machine(?x) ∧ has_drill_boom(?x, ?y)∧ Drill_boom_assembly(?y) ∧ has_feeder(?y, ?z)∧ Boom_feeder(?z) ∧ has_drill_attachment(?z, ?a) ∧ HDA(?a)∧ has_dp_port(?a, ?b) ∧ Hdp(?b) ∧ has_drill(?y, ?c)∧ has_ba_port(?c, ?d) ∧ Lba(?d)∧ is_connected(?b, ?d) −→ HL 600_700(?c)

To represent resource constraints, some built-in predicatesor functions in SWRL are required to be used. For example,swrlb:add and swrlb:greaterThanOrEqual predicates are employedin describing the resource constraint C8, as shown below. Here,the predicate swrlb:add is used to calculate the sum of parametersfrom the second to the last and then assign the sum to thefirst parameter. The predicate swrlb:greaterThanOrEqual returnstrue if the first parameter is greater than or equal to the secondparameter.C8 (Resource constraints):The total amount of power consumed by the componenttypes HL 500, HL 600 and HL 700must be less than or equal tothat supplied by the component types Engine R, Engine S andEngine W.SWRL rule:Ranger_drilling_machine(?x) ∧ has_power_unit(?x, ?y)∧ Power_unit_assembly(?y) ∧ has_engine(?y, ?z1)∧ Engine_R(?z1) ∧ supply_power(?z1, ?u1)∧ is_of_value(?u1, ?p1) ∧ has_engine(?y, ?z2)∧ Engine_S(?z2) ∧ supply_power(?z2, ?u2)∧ is_of_value(?u2, ?p2) ∧ has_engine(?y, ?z3)∧Engine_W(?z3) ∧ supply_power(?z3, ?u3)∧ is_of_value(?u3, ?p3) ∧ swrlb:add(?p0, ?p1, ?p2, ?p3)∧ has_drill_boom(?x, ?a) ∧ Drill_boom_assembly(?a)∧ has_drill(?a, ?b1) ∧ HL 500(?b1)∧ consume_power(?b1, ?v1) ∧ is_of_value(?v1, ?q1)∧ has_drill(?a, ?b2) ∧ HL 600(?b2)∧ consume_power(?b2, ?v2) ∧ is_of_value(?v2, ?q2)∧ has_drill(?a, ?b3) ∧ HL 700(?b3)∧ consume_power(?b3, ?v3) ∧ is_of_value(?v3, ?q3)∧ swrlb:add(?q0, ?q1, ?q2, ?q3) −→

swrlb:greaterThanOrEqual(?p0, ?q0)

For customer requirements that are specified in the form offunction requirements, they are required to bemapped to the con-straints on components in terms of function-component mappingrelationship. To take an example, the customer requirement R1,namely, the diameter of drilling holes should be between 72 mmand 92mm, can bemapped to this constraint on the componentHL600, i.e. this require the component HL 600, according to function-component relationships. Thus, this customer requirement R1 isdescribed in SWRL:R1 (Customer requirement):The diameter of drilling holes should be between 72 mmand 92 mm.SWRL rule:Ranger_drilling_machine(?x) ∧ has_drill_boom(?x, ?y)∧ Drill_boom_assembly(?y)∧ has_drill(?y, ?c) ∧ HL 600_700(?c) −→ HL 600(?c)

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 875

Fig. 12. Encoding classes in OWL RDF/XML.

Tomodel the above constraints, SWRL rule editor [39], a plug-inintegrated in Protégé for modeling rules, is utilized in our researchto facilitate this modeling process. These configuration constraintsin the form of SWRL rules can be encoded and saved in knowledgebases in XML files according to SWRL/XML syntax. Details aboutSWRL/XML can be referred to [12].

6. Implementing a product configuration system based on therule engine

Since SWRL is a descriptive language that is independent ofany rule language internal to rule engines, OWL and SWRL-basedconfiguration knowledge is required to be transformed into therules expressed in the rule language of some rule engine. Toimplement a product configuration system, a forward-chainingrule engine is employed in our research to performactual inferenceprocesses. We adopt JESS (Java Expert System Shell) [40], arule engine for the java platform, which is a corresponding javaversion of the CLIPS expert system. The JESS uses the forward-chaining reasoning method and implements the efficient Retealgorithm to process a number of rules. As shown in Fig. 13, thearchitecture of the developed product configurator is composedof three components: namely the JESS rule engine, the OWL2JESSand the SWRL2JESS transformers. The JESS rule engine doesactual inferences by matching the head of rules in the rule basewith the facts in the fact base. These rules whose premises aresatisfied according to matched facts are activated and wait tobe fired. Actions, such as the addition of new facts into thefact base, specified in the head of the rules are executed whenthe activated rules are fired by the inference engine. To carryout inference processes, OWL-based configuration knowledge andSWRL-based configuration constraints are required to be mappedonto JESS facts and JESS rules, respectively, which are performedby developing corresponding transformers, namely the OWL2JESSand the SWRL2JESS. The transformer OWL2JESS performs thefunction of transforming OWL-based knowledge into facts wherethe SWRL2JESS implements the transformation from SWRL rulesinto JESS rules.

6.1. The function of OWL2JESS

The classes in OWL knowledge base are mapped onto the JESStemplates that define the types of JESS facts. For example, inthe configuration knowledge base for the case study, the classesHigh_capacity_pump, Normal_pump as well as their parent classesare transformed into these following JESS templates.JESS templates(deftemplate owl:Thing (slot name))(deftemplate Component extends owl:Thing)(deftemplate part extends Component)(deftemplate Extra_fuel_filling_pump extends part)(deftemplate High_capacity_pump extendsExtra_fuel_filling_pump)

(deftemplate Normal_pump extends Extra_fuel_filling_pump)

Here, the deftemplate construct in JESS is employed to definethe type of slots in a fact. The extends construct indicates theinheritance relationship between two templates defining facts.OWL: Thing is a most top level class in OWL from which all otherclasses are directly or indirectly subclassed.

The individuals (or instances) of the OWL classes in configura-tion knowledge base are actually involved in a configuration so-lution. For instance, an individual, named iHigh_capacity_pump,which is an instance of theOWL classHigh_capacity_pump, is trans-formed into the following facts using the OWL2JESS.

JESS facts:(assert (owl:Thing (name iHigh_capacity_pump)))(assert (Component (name iHigh_capacity_pump)))(assert (part (name iHigh_capacity_pump)))(assert (Extra_fuel_filling_pump(name iHigh_capacity_pump)))

(assert (High_capacity_pump (name iHigh_capacity_pump)))

Here the assert construct in JESS is used to declare a fact, namelythat iHigh_capacity_pump is an instance of theHigh_capacity_pumptype. The declared facts will be saved in the JESS fact base.

Furthermore, some relationships between individuals or be-tween individuals and data values exist in the configuration.Such relationship facts that have been described in OWL arealso needed to be transformed into JESS facts. For instance,the relation that iPower_unit_assembly (an instance of the classPower_unit_assembly) has iTank_AUS, (an instance of the classTank_AUS) as its constituent part is transformed into the JESSfact.JESS facts:(assert (has_part iPower_unit_assembly iTank_AUS))(assert (has_tank iPower_unit_assembly iTank_AUS))

6.2. The function of SWRL2JESS

The SWRL-based constraint knowledge is transformed into JESSrules by developing the SWRL2JESS transformer. For example, theincompatibility rule C1 and the require constraint C2 and aretransformed into JESS rules, as described below.

JESS rule:(defrule C1(Ranger_drilling_machine (name ?x)) (has_fuel_tank ?x ?y)(Fuel_tank (name ?y))(has_fuel_pump ?y ?z) (has_crawler ?x ?a)(Crawler_assembly (name ?a)) (has_drive ?a ?b)(Caterpillar_drive (name ?b)) (has_track ?b ?c)(test (or (neq ?c iThree_edge_track)(neq ?z iHigh_capacity_pump) ) )=>(assert (C1_incomp ?x ?z ?c))

876 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

Fig. 13. The architecture of ontology-based product configuration systems.

JESS rule:(defrule C2(Ranger_drilling_machine (name ?x))(has_power_unit ?x ?y) (Power_unit_assembly (name ?y))(has_tank ?y ?z) (has_crawler ?x ?a)(Crawler_assembly (name ?a)) (has_drive ?a ?b)(Caterpillar_drive (name ?b)) (has_track ?b ?c)(Tank_USA (name ?z)) (Three_edge_track (name ?c)))=>(assert (C2_req ?x ?z ?c)))

The transformation of the port constraints and resourceconstraints can be handled in a similar way. In these JESS rules,the assertions (such as C2_req) that corresponding constraintshold are put into the JESS fact base when the SWRL rules aretransformed. Both OWL2JESS and SWRL2JESS are developed byusing the Extensible Style-sheet Language Transformations (XSLT)to perform the transformation from XML documents to JESS files.For manipulating these XML documents according to the DOM(Document Object Model) [49] and SAX (Simple API for XML) [50]specifications, the Xerces Java Parser [41], a Java XML parser, isutilized to develop these transformers in our research.

6.3. The execution of JESS inference engine

By importing JESS files containing both JESS rules andfacts derived by the transformers OWL2JESS and SWRL2JESS,configuring processes are carried out by the inference engine. Theengine applies the rules to facts in the fact base, and activates therules whose premises are satisfied, fires the activated rules andexecutes the actions specified in the head of these activated rules.The process is finished until no rules are in the rule base, and thenthe configuration results are derived and displayed. For the caseconfiguration, there is a total of 499 facts in the fact base and of14 rules in the rule base. It takes the configurator 9 seconds to getthe configuration solutions on a personal computer with PentiumDual-Core CPU and 512 Mmemory. As shown in Table 2, there aretwo configuration solutions, one of which has been described inSection 5. It can be verified that the configuration solutions satisfyall constraints and customer requirements specified in the caseconfiguration.

7. Conclusion

As the structures of configurable products and technicalconstraints among components become increasingly complex,automatically configuring a customizable product tailored toa customer’s requirement becomes a challenging task. In thispaper, we adopt an expressive OWL ontology language and aSWRL rule language to model product configuration knowledge in

Table 2Configuration solutions

Solutions Individuals involved in the configuration. (the components thatare not shown below are not included in this configuration)

Solution 1 iHigh_capacity_pump (an individual of High_capaicty_pump)iEngine_W (an individual of Engine_W)iEngine_R (an individual of Engine_R)iTank_EURO (an individual of Tank_EURO)iHDA; (an individual of HDA)iHdp; (an individual of Hdp)iHL 600 (an individual of HL 600)iHba_1; (an individual of Hba)iNormal_track (an individual of Normal_track)iWinch (an individual of Winch)iRear_jack (an individual of Rear_jack)iAC5; (an individual of AC5)has_dp_port(iHDA, iHdp);has_ba_port(iHL 600, iHba_1);is_connected(iHdp, iHba_1);. . . . . . . . .

Solution 2 iHigh_capacity_pump (an individual of High_capaicty_pump)iEngine_W (an individual of Engine_R)iEngine_W (an individual of Engine_W)iTank_EURO (an individual of Tank_EURO)iHDA; (an individual of HDA)iHdp; (an individual of Hdp)iHL 600 (an individual of HL 600)iHba_1; (an individual of Hba)iNormal_track (an individual of Normal_track)iWinch (an individual of Winch)iRear_jack (an individual of Rear_jack)iAC5; (an individual of AC5)has_dp_port(iHDA, iHdp);has_ba_port(iHL 600, iHba_1);is_connected(iHdp, iHba_1);. . . . . . . . .

which structural knowledge is represented in OWL and constraintknowledge is described in SWRL. The advantage of OWL-basedconfiguration models is that the reuse of configuration modelscan be ensured since OWL, as an ontology language, supportsknowledge reuse and sharing. This is especially crucial, consideringincremental changes and updates on products due to newtechnology advances. The actual product configuring process isimplemented using a JESS rule engine by mapping OWL-basedconfiguration knowledge and SWRL-based constraint knowledgeinto JESS facts and JESS rules, respectively. The presented approach,which separates configuration knowledge representation fromactual configuration inference processes, is flexible in choosing theimplementation platforms (such as JESS, Prolog [48]). Furthermore,making use of an existing rule engine, namely JESS, facilitates rapiddevelopment of a product configurator. However, the presentedresearch only deals with finding feasible solutions for productconfiguration. In the case that several configuration solutions exist,

D. Yang et al. / Computer-Aided Design 40 (2008) 863–878 877

an algorithm to obtain an optimal configuration in terms of someobjective is required to be developed. This should be considered inthe further work.

Acknowledgements

The work presented in this paper has been supported by grantsfrom National Natural Science Foundation of China (Project No.70471023) and Program for New Century Excellent Talents inUniversity of China.

References

[1] Sabin D, Weigel R. Product configuration frameworks — A survey. IEEEIntelligent System 1998;13(4):42–9.

[2] Stumptner M. An overview of knowledge-based configuration. AI Communi-cation 1997;10(2):111–25.

[3] Haag A. Sales configuration in business processes. IEEE Intelligent Systems1998;13(4):78–85.

[4] Tiihonen J, Lehtonen T, Soininen T, Pulkkinen A, Sulonen R, Riitahuhta A.Modeling configurable product families. In: Proceedings of 4thWDKworkshopon product structuring. 1998.

[5] Barker VE, O’Connor DE. Expert systems for configuration at Digital: XCON andbeyond. Communications of the ACM 1989;32(3):298–318.

[6] Mittal S, Frayman F. Towards a generic model of configuration tasks. In:Proceedings of the 11th international joint conference on artificial intelligence.1989.

[7] Mittal S, Frayman F. Dynamic constraint satisfaction problems. In: Proceedingsof the AAAI conference. 1990. p. 25–32.

[8] Freuder EC. The role of configuration knowledge in the business process. IEEEIntelligent Systems 1998;13(4):29–31.

[9] Gruber TR. Ontolingua: Amechanism to support portable ontologies. Technicalreport KSL 91-66. Stanford University, Knowledge Systems Laboratory, 1991.

[10] McGuinness DL, vanHarmelen F. OWLweb ontology language overview, 2003.http://www.w3.org/TR/owl-features/.

[11] Horrocks I, Patel-Schneider PF, van Harmelen F. From SHIQ and RDF to OWL:The making of a web ontology language. Journal of Web Semantics 2003;1(1):7–26.

[12] Horrocks I, Patel-Schneider PF, Boley H, Tabet S. SWRL: A se-mantic web rule language combining OWL and RuleML. 2004.http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/.

[13] Friedman-Hill E. Jess in action: Rule-based systems in Java. Greenwich:Manning Co.; 2003.

[14] Hong G, Hu L, Xue D, Tu YL, Xiong YL. Identification of the optimal productconfiguration and parameters based on individual customer requirements onperformance and costs in one-of-a-kind production. International Journal ofProduction Research 2007;1–30. doi:10.1080/00207540601099274. iFirst.

[15] Zhou C, Lin Z, Liu C. Customer-driven product configuration optimization forassemble-to-order manufacturing enterprises. The International Journal ofAdvancedManufacturing Technology 2007; doi:10.1007/s00170-007-1089-6.

[16] Li B, Chen L, Huang Z, Zhong Y. Product configuration optimization usinga multiobjective genetic algorithm. The International Journal of AdvancedManufacturing Technology 2006;30(1–2):20–9.

[17] Yeh JY,Wu TH, Chang JM. Parallel genetic algorithms for product configurationmanagement on PC cluster systems. The International Journal of AdvancedManufacturing Technology 2007;31(11–12):1233–42.

[18] Tseng HE, Chang CC, Chang SH. Applying case-based reasoning for productconfiguration in mass customization environments. Expert Systems withApplications 2005;29:913–25.

[19] Lee HJ, Lee JK. An effective customization procedure with configurablestandard models. Decision Support Systems 2005;41(1):262–78.

[20] Tsang E. Foundations of Constraint Satisfaction. London: Academic Press;1993.

[21] Fohn SM, Liau JS, Greef AR, Young RE, O’Grady PJ. Configuring computersystems through constraint-based modeling and interactive constraintsatisfaction. Computers in Industry 1995;27(1):3–21.

[22] Xie H, Henderson P, Kernahan M. Modelling and solving engineering productconfiguration problems by constraint satisfaction. International Journal ofProduction Research 2005;43(20):4455–69.

[23] Felfernig A, Friedrich G, Jannach D. Conceptual modeling for configurationof mass-customizable products. Artificial Intelligence in Engineering 2001;15(2):165–76.

[24] Ong SK, Lin Q, Nee AYC. Web-based configuration design system for productcustomization. International Journal of Production Research 2006;44(2):351–82.

[25] KimKY,Manley DG, YangH. Ontology-based assembly design and informationsharing for collaborative product development. Computer-AidedDesign 2006;38(12):1233–50.

[26] Yang QZ, Zhang Y. Semantic interoperability in building design: Methods andtools. Computer-Aided Design 2006;38(10):1099–112.

[27] Ciocoiu M, Nau DS, Gruninger M. Ontologies for integrating engineeringapplications. Journal of Computing and Information Science in Engineering2001;1(1):12–22.

[28] Ahmed S, Kim S, Wallace KM. A methodology for creating ontologiesfor engineering design. Journal of Computing and Information Science inEngineering 2007;7(2):132–40.

[29] Witherell P, Krishnamurty S, Grosse IR. Ontologies for supporting engineeringdesign optimization. Journal of Computing and Information Science inEngineering 2007;7(2):141–50.

[30] Liang VC, Paredis CJJ. A port ontology for conceptual design of systems. Journalof Computing and Information Science in Engineering 2004;4(3):206–17.

[31] Cho J, Han S, Kim H. Meta-ontology for automated information integration ofparts libraries. Computer-Aided Design 2006;38(7):713–25.

[32] Uschold M, King M. Towards a methodology for building ontologies. In:Proceedings of IJCAI95’s workshop on basic ontological issues in knowledgesharing. 1995.

[33] Smith MK, Welty C, McGuinness DL. OWL web ontology language guide.W3C recommendation. 2004. http://www.w3.org/TR/2004/REC-owl-guide-20040210/.

[34] Baader F, Calvanese D, McGuinness D, Nardi D, Patel-Schneider P. TheDescription Logic Handbook: Theory, Implementation and Applications.Cambridge University Press; 2002.

[35] Patel-Schneider PF, Hayes P, Horrocks I. OWL web ontology lan-guage semantics and abstract syntax. W3C recommendation, 2004.http://www.w3.org/TR/owl-semantics/.

[36] PROTÉGÉ (2007). Protégé Ontology modeling tool.http://protege.stanford.edu/.

[37] Sintek M. OntoViz Tab plug-in for Protege. 2007. http://protege.cim3.net/cgi-bin/wiki.pl?OntoViz.

[38] Horrocks I, Patel-Schneider PF, Bechhofer S, Tsarkov D. OWL rules: A proposaland prototype implementation. Journal of Web Semantics: Science, Servicesand Agents on the World Wide Web 2005;3(1):23–40.

[39] O’Connor M. Protégé SWRL editor. 2007.http://protege.stanford.edu/plugins/owl/swrl/.

[40] Jess Rule Engine. http://herzberg.ca.sandia.gov.[41] Xerces. Xerces java parser readme. 2001. Available online at:

http://xerces.apache.org/xerces-j/.[42] Altuna A, Cabrerizo A, Laresgoiti I, Pena N, Sastre D. Co-operative and

distributed configuration. Lecture notes in computer science (LNCS), vol. 3263.2004. p. 69–80.

[43] Zhang JS, Wang QF, Wan L, Zhong YF. Product configuration modeling basedon ontology. Computer Integrated Manufacturing Systems 2003;9(5):344–50.

[44] Soininen T, Tiihonen J, Mannisto T, Sulonen R. Towards a general ontologyof configuration. Artificial Intelligence for Engineering, Design, Analysis andManufacturing (AI EDAM) 1998;12(4):357–72.

[45] Kalinichenko LA,MissikoffM, Schiappelli F, SkvortsovN.Ontologicalmodeling.In: Proceedings of the fifth Russian conference on digital libraries. 2003.

[46] Salvador F, Forza C. Configuring products to address the customization-responsiveness squeeze: A survey of management issues and opportunities.International Journal of Production Economics 2004;91(3):273–91.

[47] OMG (Object Management Group), Unified modeling language.http://www.omg.org/technology/documents/formal/uml.htm.

[48] Clocksin WF, Mellish CS. Programming in Prolog: Using the ISO standard. 5thedition. 2003.

[49] W3C. Document Object Model (DOM). http://www.w3.org/DOM/.[50] Simple API for XML (SAX). http://www.saxproject.org/.[51] W3C. RDF vocabulary description language 1.0: RDF schema.

http://www.saxproject.org/.[52] Genesereth MR, Fikes RE. Knowledge interchange format reference manual.

Technical report. Computer Science Department, Stanford University, 1992.[53] Corcho O, Fernandez-Lopez M, Gomez-Perez A. Methodologies, tools and

languages for building ontologies. Where is their meeting point? Data &Knowledge Engineering 2003;46(1):41–64.

[54] RACER (2007). RacerPro reasoner, Racer Systems GmbH & Co. KG.http://www.racer-systems.com/.

Dong Yang is currently an Associate Professor with theDepartment of Industrial Engineering and Managementat Shanghai Jiao Tong University, China. He receivedhis PhD degree in Computer Science from ShanghaiJiao Tong University. He also holds his BS and MSdegree inMechanical Engineering from Fuzhou Universityand University of Electronic Science and Technologyof China, respectively. His research deals with productconfiguration, ontology-based knowledge representationand object-oriented modeling. He published severalarticles in international journals such as Experts Systems

with Applications, International Journal of Production Research, InternationalJournal of Computer Integrated Manufacturing.

878 D. Yang et al. / Computer-Aided Design 40 (2008) 863–878

Ming Dong received PhD in Industrial Engineering fromVirginia Polytechnic Institute and State University in 2001.He also holds a BS degree in Mechanical Engineering,and obtained MS and PhD in Mechanical Engineeringfrom Tianjin University in 1994 and 1997, respectively.His research interests are in supply chain management,modeling and analysis of logistics systems, platform-based product design, and product line optimization.He is a member of IIE, INFORMS and SME. He haswon many awards and honors for his research and haspublished extensively in respected scholarly journals suchas European Journal of Operational Research, MechanicalSystems and Signal Processing.

Rui Miao is an Associate Professor with the Departmentof Industrial Engineering and Management at ShanghaiJiao Tong University, China. His research interests are in-dustrial engineering and management, quality manage-ment, computer integrated manufacturing system (CIMS).He holds his PhD degree in Mechanical Engineering fromHarbin Institute of Technology.