Configuration - SoberIT

Configuration Workshop at ECAI 2000Program CommitteeMichel Aldanondo, Ecole des Mines d'Albi CarmauxDean T. Allemang, Synquiry Technologies Ltd.David Brown, Worcester Polytechnic InstituteBoi Faltings, Swiss Federal Institute of TechnologyGerhard Friedrich, University of KlagenfurtEugene Freuder, University of New HampshireEsther Gelle, ABB Corporate Research Ltd.Albert Haag, SAP AGBeat Liver, Credit Suisse Private BankingDaniel Mailharro, ILOG S.A.Hans Jørgen Skovgaard, BAANTimo Soininen, Helsinki University of TechnologyReijo Sulonen, Helsinki University of TechnologyMarkus Stumptner, Technische Universität Wieniii

Unified Configuration Knowledge Representation Using Weight Constraint Rules / 79Timo Soininen, Ilkka Niemelä, Juha Tiihonen, Reijo SulonenOptimizing Configurations / 85Tommi SyrjänenDemo DescriptionsIPAS: An Integrated Application Toolsuite for the Configuration of Diesel Engines / 91Carlo BachEngCon - A Flexible Domain-Independent Configuration Engine / 94Oliver Hollmann, Thomas Wagner, Andreas GuenterAcknowledgement: Final document preparation by Margit Rudelstorfer.vi

PrefaceThe ECAI 2000 Workshop on Configuration is the third in a series of international meetingson configuration that began with the 1996 AAAI Fall Symposium in Boston, USA, andcontinued with the AAAI’99 Configuration Workshop in Orlando, USA.Configuration tasks can be defined as the design of an individual product using a set of predefinedcomponents or component types while taking into account a set of well-definedrestrictions on how the components can be combined. This task can be supported by applyinga wide range of AI techniques such as rule-based systems, constraint satisfaction and itsextensions, description logics, logic programs, and different specialized problem solvingmethods.Among the original application areas of the early expert systems, Configuration research has along history, but has recently attracted a lot of research and industrial interest. The researchinterest is witnessed by the high turnout to events such as the AAAI'99 Workshop onConfiguration. The industrial interest is indicated by the increasing number of vendors ofsoftware tools for configuration, i.e. configurators. The importance of configuration hasexpanded as more companies use configurators to efficiently customize their products forindividual customers, and especially with the trend towards providing configuration supportto the customers themselves (whether corporate or individual) via the Web.However, efficient development and maintenance of configurators require sophisticatedsoftware development techniques. AI methods, more than ever, are central to developingpowerful configuration tools and to extending the functionality of configurators.Configuration problems, like planning problems, can be seen on one hand as an interestingtest-bed for novel AI techniques. On the other hand, configuration problems can serve asinput for new research directions. The seventeen papers included in these pages, dealing withtopics such as modeling, efficient algorithms, testify to the relevance and technical challengepresented by configuration problems.The Organizersvii

viii

!"#$% !"#$%&'" $!& %% ' ( & ' ) * + %$ , - - $ - - % )% !." !/"* )- -* )00 +1 20 !3" 4 !5"* ( 4 % ' ' % 6' ' + ' ( % 4 ' #$ 7) * '$!( &#" $! )#$*+,- '$!( &#"$#-!%#,.& #,,!"- / 6%% ' ,, '% , % ' % ' ' )* ?&' # 1 @4' A' ? +:

.,%'/, $ ,)*')*')*/')* %'3, ,)*')*3')* %' $ %'5, ,)*')*5')*% '8, 8 % + '$E%' > E ,9.E)>*.8'5*9.H5 9. < ') .8* /% & E % 3 ?%4 4'(2 22 ' / & '8 2 6 $' / + /% $,,%', ' ) % *'( '.,%'/, $ ,)*')*')*/')* %'3, ,)*')*3')* %'5, ,)*')*5')* '8, 8 % 23 ' / D ' $ )' ' J*% 6 $ -> 9. - '>.8/ % + - - 3,3, 3 $ ' )* )* 3' 1 ' % 6 ' '3,3, 3 $ ' )*')*3 )*3'25 ' / & % ' & ' D % % 6' > !5"6 ' )*' ,,%', ( '.,%'/, $ ,)*')*')*/')* %'3, ,)*')*3')* %'5, ,)*')*5')*% '8, 8% /

& ' )>'E 7* @ +' , %' > 7 > 7231 412 34+ '$ ) ' ' '*+ '%' ( ,37'./E ./3>(3 6 ' % )*' ,,%', ( '. /,%'3, 3 % '5, ,)*')*5')* '8, 8 % +$326 ' # ' 5 ' > ' 4 !8" - - - - - - . .. ./ .3 .5 K K K K K+ K K K K(5 D ' % 4!9" !/"% ,) +*, % % ' ' '% )4+*, % % ' ' ' %)1+*, % % ' ' ' %D ' - -)+* ,+ +, & C% '+4+, & ' ' % '+1+, % % %'% 3

¢£¤Jérôme Amilhastre and Hélène Fargier ¡Handling interactivity in a constraint-basedapproach of configurationAbstract. A configurable product can be represented by means of aConstraint Satisfaction Problem (CSP) the solutions of which are feasibleproducts. Within an interactive configuration process, the finalproduct cannot be generated by solving automatically the CSP; instead,the user specifies his requirements by the interactive choice ofvalues for the different variables. The role of a decision support systemis then to ensure at any time that the current set of user choicesis consistent and to prune the domains of available values so as tokeep them consistent with the choices. It also has to guide the relaxationby providing restorations, i.e. by identifying maximal consistentsubsets of the user restrictions. This paper presents a frameworkto constraint-based configuration in which these functionalities areoffered. It is based on an extension of the CSP framework in the spiritof ATMS. It relies on a pre-compilation of the initial CSP under theform of an automaton. This data structure is then used to maintainconsistency and to compute restorations.1 IntroductionConstraint programming techniques are widely used to model andsolve decision problems. Most algorithms developed in this area focuseson the automatic solving of the problem. This does not helpsolving decision support problems that are interactive in nature. Inthis kind of application, the user himself chooses the values of thevariables: the role of the system is not to solve a Constraint SatisfactionProblem, but to help the user in this task.It is the case in the domain of product configuration: a configurableproduct is defined by a set of components, options, more generallyby a set of attributes, the values of which have to be chosen bythe user. These values must satisfy a set of configuration constraintsthat encode the feasibility of the product, the compatibility betweencomponents, their availability, etc. At a first glance, a configurableproduct can then be represented by means of a CSP 3 . The set of solutionof this CSP represents the catalog, i.e. all the variants of theconfigurable product that the company proposes.When configuring a product, the user specifies his requirementsby the interactive choice of values for the different variables or moregenerally by the definition of unary constraints that restrict the possiblevalues of the decision variables. After each new choice, the do-LIRMM, 161 rue Ada, 34392 Montpellier, France, amilhast@lirmm.frIRIT, 118 route de Narbonne, 31062 Toulouse, France, fargier@irit.frThis is obviously an approximation: a product is often structured into subcomponents,the existence of which depends on the value given to someof the variables of the upper component. Several authors have proposedto extend the CSP framework in order to handle such structural characteristics[9, 7, 10, 11]. However, these works do not address the interactivyof the configuration task, and assume that the requirement of the user arecompletely given before the solving phase. The two ways of research (interactivityand structuration) are rather complementary than opposite.mains of the variables have to be pruned so as to guarantee that thevalues available can lead to a feasible product (i.e. a product satisfyingall the constraints of the CSP). Finally, if the current set ofchoices becomes inconsistent with the constraints, or if the availablevalues do not satisfy the user, he will backtrack on previous choicesand relax some of them. Therefore the help provided by the decisionsupport system should be to:¥Maintain consistency: The system has to ensure at any time thatthe current set of user choices is consistent with the CSP modelingthe configurable product, or at least to detect inconsistency as soonas possible. It has also to compute the consequences of the actionsof the user by deleting (resp. restoring) all the values that are incompatible(resp. compatible) with the current set of choices: the currentdomains should obey the property of ”global consistency” or at leasta property of local consistency, e.g. arc-consistency.¥Guide relaxation on user requirements by providing restorations:the system has to help the backtrack in answering the followingquestions of the user: ”Which choices can I relax in order torecover consistency ?” or ”Which choices can I relax in order to havethis value available ?”. The idea is thus to identify consistent subsetsof the current set of user restrictions, possibly maximal consistentsubsets or consistent subsets minimizing a cost function.¥Provide explanations of the conflicts: The system has to answerthe questions ”Which subset of restrictions do cause the inconsistency?”or ”Why isn’t this value available any more?”. The idea isthus to identify (minimal) inconsistent subsets of restrictions.Classical filtering algorithms, and above all, their dynamical versions(c.f. [1][2][6]) may address the first functionality, withoutproviding any guarantee of global consistency. However, these algorithmscannot help the computation of restorations. This paperpresents an approach of constraint-based configuration that addressesthese functionalities. The next Section proposes an extension of theCSP framework that allows the modeling of the task of configuration.Our approach relies on the computation of an automaton thatrepresents the initial CSP, as proposed by [13]. . The principles ofthis compilation are briefly recalled in Section 3. In Section 4, wepresent how this data structure is used to perform the task of consistencymaintenance and to provide the user with restorations.2 A constraint-based approach of configuration2.1 Modeling the configurable productA CSP is classically defined §©¨by ¨a ¦ triplet whereis a finite set of variables, each taking its values!#"%$ in a !#"'&)('!#"%*+(,-.(/!#"%0 finite domain (where = ), and ¢ £ a set of 1 constraints . A constraint 234165,78¨in is defined on7

and restricts the combinations of values that can be taken by the variables234165 of . A 9#34165 relation 234165 on can be associated with1 each : it is the set of tuples that satisfy the constraint. In the following,denotes the constraint 234165 on that is satisfied by any tuple:;1that 1 violates and violated by any tuple that 1 satisfies .An < instanciation is an element of ; it is a solution of theCSP if it satisfies all the constraints, i.e. if, for any constraint 1 , theprojection < of 234165 on is an element 9 34165 of < (otherwise, is saidto 1 falsify ). If such a solution ¦ exists, is said to be consistent,otherwise it is inconsistent.In constraint-based configuration, the idea is to encode the configurableproduct by a CSP. Since each solution of the CSP correspondsto a variation of the product, we can reasonably suppose that it isconsistent. Since it is possible to realize an off line pre-computingon the CSP (this pre-computing is not realized during the configurationphase, but takes places in the design of the configurator, oncethe generic product has been modeled by the expert), we can supposethat the initial CSP is globally consistent, i.e. that for any value in thedomain of any variable, there is a solution that assigns this value tothe variable. One of the tasks of the system will be to keep the problemglobally consistent during the configuration phase, i.e. after eachaddition or deletion of a user choice.2.2 Modeling the requirements of the userThe choices of the user deal with individual variables: an elementarychoice is a unary constraint. This encompasses both the assignmentof a precise value to a variable or the reduction of a domain to asubset of values that equally satisfy the user. Hence, we will representthe current set of user choices by a set = of unary constraints.In this context, we can define the notion of ”Assumption-based”CSP. This kind of CSP that relies on a distinguished set of constraintsis an extension to non boolean domains of the so-called ”Assumptionbased Truth Maintenance Systems”, = playing the role of the set ofassumptions:whereis a CSP = and a set of unary constraints on variablesDefinition 1 a A-CSP ¦ is a quadruplet §>¨?=@§©ÄBCD¨ of .will represent the = §E¨© configurable product and thecurrent set < of user restrictions. An ¦instanciation is a solution ofif ¦GFH#§8¨(=I is a solution of , which < is the (classical)¦ F CSP associated with : defines the feasible products that ¦ satisfiesall ¦ the requirements of the user. is consistent (resp. inconsistent)iff is consistent (resp. KG3L¦65 inconsistent). At any time, , ¦JF the set ofsolutions of corresponds to the set of the products that ¦ obey therequirements of the user. MH" $ For each , will be the projection ofon : it is the set of all the values of the choice of which KN3L¦N5allows the definition of a feasible product = that satisfies .defines a subset = of that can be relaxed so as to recover consistency:O if is a consistent environment, it is sufficient for the user to relaxin order to recover consistency.=WVXOFor instance, §YÄBZif is consistent §Y¨?=[andis = inconsistent, is a trivial \ conflict, a consistent environment anda dummy solution is obtained by relaxing all the constraint = of .This example also shows that all the environments are not equallyinteresting in practice. In real applications, the user choices do notnecessarily have the same importance, but may be subject to preferences.For instance, a requirement dealing with the type of engine canbe more important than a restriction concerning the color of the bodyof the car. In order to allow the handling of preferences, we proposeto associate with each ]_^P= constraint a `?3a]5b^Zc%d valuation :the higher the valuation, the more important the constraint. In the following,we suppose that every constraint has a positive importance(otherwise, it can be a priori discarded = from ). In this context, thebest consistent environments ones are those that minimize the sum ofthe valuations of the relaxed constraints, or, equivalently, that maximizethe sum of the valuation associated with the constraints theykeep. In particular, ` when is the constant e function , the best consistentenvironments are those that involve the larger number of constraints.Symmetrically, preferences can be used to discriminate themore or less interesting causes of the inconsistency, the best ones beingthe minimal ones: conflicts involving the less constraints will bepreferred, or more generally the ones that minimize the sum of thevaluations of the constraints involved. More formally:Definition 3 Let ¦f#§©¨?=> be a A-CSP, ` a valuation ofthe assumptions, i.e. a positive application from = to c and for anyOE^U= , let `?3aOb5?fg8hjilk `?3a]5 .A V-optimal conflict = on (or 2 a -nogood) is a O conflict ¦ ofsuch that there is no other O6F conflict ¦ of such `?3aO6Fm5/no`?3aOb5 that .2 A -maximal consistent environment ( 2 or -interpretation) ¦ ofis an environment consistent ¦ with such that there exists no otherO6F environment consistent ¦ with and such `%3aO6Fp5/q©`?3aOb5 that .It could be interesting to use other structures of valuation as suggestedin [12]. We restrict this paper to §Zcj(sr6tolthe structurewith ` a giving valuations different from and u . Thischoice allows the representation of several optimality criteria for theenvironments, such as those based on cardinality or lexicographicr6tordering. It ensures a polynomial computation of the score of environmentsand thus a polynomial comparison between them.Explanations and restorations Even if the current set of restrictionsis not inconsistent with the CSP, it can forbid some values forother variables that the user would prefer to be available. The systemmust thus explain to the user a cause for these prohibitions:Definition 4 Let ¦v#§W¨?=w be a A-CSP and x a unaryconstraint on a variable of ¨ .Conflicts and consistent environments. In the following, we referto OE7P= subsets of user choices as environments.Definition 2 ¦Q#§RÄB?=S Let be a A-CSP. An environmentis ais consistent (resp. inconsistent) ¦ with §TÄBU(OIiffconsistent (resp. inconsistent) CSP. Any inconsistent environment iscalled a conflict ¦ for (or a conflict = on for ).When §©ÄCD is consistent, a conflict can be understood as acause of the inconsistency the inconsistency of the user requirementswith the configuration constraints and any consistent environmentx ¦ O §:%x¨(UOEAn explanation of on is an environment such thatis a consistent CSP §y¨CB(UO©(andis an inconsistent one.Determining why a set 2 of values is not available any more for agiven variable is indeed equivalent to determining which subsetsof are inconsistent with the constraint ” ”, i.e. to compute= C~ ^z2. 2| ^}!the explanations of the x{R|constraintThe user not only needs to understand why some values are forbidden,but also and most of all to know which previous choices canbe relaxed in order to make these values available again. This leadsto the definition of the notion of restoration:8

•î~îrËËÓîr•îr~rrÓîäpath supports a value for a variable (resp. a unary constraint) iff itcontains an edge supporting this value (resp. this unary constraint).Computing the automaton associated with a CSP. Following[13], the automaton associated with a can be built by using classicaloperators on automata: either by any CSP algorithm that enumeratesthe set of solutions and adds them successively to the automaton,or by composition operators on (small) automata representing theconfiguration constraints. The complexity of the computation of theautomaton and of its use depends on its size. This size is mainlyinfluenced by (i) the order on the variables in the automaton and (ii)the algorithm used to built it. Vempaty [13] has proposed to buildthe DFA that minimizes the number of states. It is also possible torefer to other minimization algorithms, that build smaller automata(non-deterministic ones).3.2 A-CSP with valuations and weighted automata.Recall that =each element of is ] " $ a unary constraint on a variableand is valuated `?3a] " $5 by ; it forbids some assignmentsof , and thus some of the edges: namely any edge such that Š and ‰lŠŒ‹C3LŠ 5GÑ ^A9 3a]#"%$Ï5 . The principle of our approach‰lŠ+Å 3LŠ 5?is to associate a weight `%3LŠ 5S`%3a] " $Ï5 to Š each edge: if correspondsto an assignment forbidden ] " $ by `?3LŠÒ5Jvua restriction ,otherwise. We can thus define:ÓÔ3L¾5%fg i)ÕÖ-× ÖÙØ`?3LŠ 5 – , the weight of a ¾ path ,ÓÔ3LŠ 5 – the weight of the best (i.e. with minimal weight) path fromto through edge Š ,ÓÔ3L—l5 – the weight of the best path from to through — state4 Answering the requests using the automatonNow, since every constraint of =has a positive valuation, any pathfrom to of zero weight (or ”null path”) defines a feasible productthat satisfies all the user requirements and any non null path correspondsto a product that violates at least one of the restrictions of= . Knowing the set of paths with a null weight is thus equivalent toknowing the set of solutions of §©ÄB(‚=> .¦„#§Ÿ¨?=… `‡¦ x¾ O`%3aOb5%y`?3L=‚5?VUÓÔ3L¾)5ÚÜÛ ¾ OÓÔ3L¾Ý5/Þo`?3L=‚5?VX`?3aOb5x O¾x `?3aOb5;y`?3L=‚5ÔVÓÔ3L¾)5O xXÚ¿Û ¾ÓÔ3L¾Ý5/Þ©`?3L=‚5?Vz`?3aOb5 xProposition 7 Let be a A-CSP, a positivevaluation of its assumptions and a weighted automaton representing. Let be a unary constraint. It holds that:a) Any path from to defines a consistent environment suchas .b) is a consistent environment a path from to suchthat .c) Any path from to that supports defines a restorationof such a .d) is a restoration of a path from to that supportssuch that .Sketch of proof:– A path from to defines a complete assignment of that isa solution of . The weight of this path is equal tothe valuation the subset of constraints = in that are violated bythis solution. Let us denote this OYy=VX subset. is thus aconsistent `?3aOb5?y`?3L=RVB5%f`?3L=‚5ŒV`%3a5%environment.. `%3L=‚5ÔVUÓÔ3L¾Ý5– Conversely O let be a consistent environment. There is a solution< of §S¨CBY that satisfies all the constraints in O .Since all the solutions of §W¨o are represented by theautomaton, < to corresponds a ¾ path ÓÔ3L¾)5 . is equal to the valuationof the subset of constraints = in that are violated < by .Let us denote this ÓÔ3L¾Ý5jE`?3a5 subset: . Ÿ78=Wß,O Since ,.ÓÔ3L¾)5/ào`%3L=‚5ÔVX`%3aOb5– A ¾ path from to that x supports defines a complete assignment¨ of that is a < solution §©¨Dof and that satisfies. ÓÔ3L¾Ý5 is equal to the valuation the subset of constraints in =xthat are violated < by . Let us denotethus a restoration x of `?3aOb5?y`%3L=fV5;y`?3L=‚5VA`?3a5?.this subset. OYR=Zßš is`?3L=‚5ÔVÓÔ3L¾)5O x ¨Y.– Conversely let be a restoration of . There is a solutionof that satisfies and all the constraints in .Since all the solutions §E¨©of are represented by theautomaton, < to corresponds a ¾ path which x supports ÓÔ3L¾)5 .is equal to the valuation the subset of constraints = in that areviolated < by . Let us denote this ÓH3L¾Ý5'Q`?3a5 subset: . SinceâProposition 7 allows the formulation in terms of optimal paths ofmost of the requests identified in Section 2.3. It indeed allows toprove that:á7P=E߃O , ÓÔ3L¾Ý5/ào`?3L=‚5?VX`?3aOb5 .Proposition 8a) Every minimal path from to represents a V-optimal interpretationof and conversely, to any V-optimal interpretationcorresponds at least one minimal path.= b) is a conflict ¦ for iff there is no null path from to .Ð^}M¡"%$ c) iff there is an Š edge such ‰lŠ+Å 3LŠ 5?that ‰lŠŒ‹C3LŠ 5? ,and Š belongs to a null path from to .Ðd) x Let be a unary constraint on ^8¨ , ãNä the set of edgesthat support it and ãNå). Each edge ãNå ä in defines athe cheapest of them (ã6å ŠS^ää ÓÔ3LŠ 5BI‘Æa£ Ø iÝæç ÓH3LŠ F 5ã-optimal restoration of x and to any 2 -optimal restoration of2corresponds at least one edge in ã å ä .xHence, the requests we are interested in can be reduced to the determinationof some minimal paths in the automaton. To allow anefficient computation of these minimal paths, let us maintain for any— state of the automaton:– Óè+3L—Ý5yêéyÆa£weight of the paths from — to ,Ó –weight of the paths — from to ,iìë Ø Í 3ÌÓè+3L—l5ÉÏíCîìÊÌËØ iºë 3L—Ý5P’éyÆa£ Í 3ÌÓÉÏíCîìÊÌËÓè+3LŒ5?ÀÓ 3a5%yu – .3L—ºFL5`?33L— Ï—ºFm55 is the minimal`?33L—Œ—sFp55 is the minimalÓÔ3L—Ý5 —ÓH33L— — F 55 3L— — F 5, the weight of the minimal path from to through , andthe weight of the minimal path from to through ,can be directly deduced from these quantities:Proposition 9ÓÔ3L—Ý5%{Ó è 3L—Ý5 3L—l5 – ,ÓÔ33L—Œ—ºFm55%ÀÓ è 3L—l5 `?33L—Œ—sFp55–. 3L—ºFm5Finally, in order to ensure an efficient computation of the MH" $ sets ,for any pair variable-value 3 ÐŒ5 .ÐŒ5¾-£šï3 ÐŒ5RÐwe maintain a counteris the number of edges that (i) support the instanciationand (ii) belong to a null path from to . ;ð ¾Î£šï34.1 Adding and deleting restrictionsSuppose that the user just adds = to a ] constraint. Some of the edges thus become forbidden: the Š5on with the`?3a] valuation. It is thus necessary5to update the weight of these edges: since no other constraint = ofsuch that ‰lŠ+Å 3LŠ 5and ‰lŠŒ‹C3LŠ 5^y9 3a]10

~îîrÐÓî~rÓîîrÓîrrrrrrÓî]]5 u `?3a] 5 = ]‰lŠ+ÅŒ3LŠ 5? Š^f9 ‰lŠŒ‹C3LŠ 5= 3a]5restricts , the weight of these edges must rise from to .Conversely, if the user relaxes and deletes it from , some of theforbidden edges become allowed: the edges such thatand . Since no other constraint of restricts ,their weights come down u to . In both cases, the modification of theweight of an edge has to be propagated back (to update Ó 345 the ) andforward (to update Ó è 345 the ). This can be done in three steps:1) Determination of the edges such ‰lŠ+ÅŒ3LŠ 5? thatby a ‰lŠ ‹Ù3LŠÒ5 value that does not belong 9 3a] toand labeled; updating of their5` weights .2) Backward propagation from the right states of these edges to theinitial state: this is done with a breath-first strategy, so as to updatethe Ó weightssuccessors.3) Forward propagation from the left states of these edges to thefinal state: it is also done with a breath-first strategy, so as to updatethe left weights Ó è 345 of the traversed states knowing the left weightsof their successors.The ¾-£šï-345 counters are maintained as follows: for any edge Š encountered,¾-£šï3L‰lŠ+ÅŒ3LŠÒ5ÎC‰lŠŒ‹C3LŠ 55 is incremented if ÓÔ3LŠ 5 rises from 0to a positive value and decremented if it comes down to 0.This kind of algorithm is polynomial in the size of the automaton.Linear implementations can be proposed that rely on a judiciouschoice of the data structure that encodes the automaton. The practicalefficiency of this kind of algorithm can obviously be enhanced, forinstance by a propagation of the modifications only (in practice, thepropagation has seldom to reach the extremities of the automaton).345 of the traversed states knowing the weights of their4.2 Detection on the inconsistencyMaintaining the weighted automaton allows us to determine at anytime whether the current set of assumptions (i.e. the current set ofuser choices) is consistent with the initial CSP. Indeed:represented by more than one path. Two different methods can beproposed for the enumeration of these interpretations. The first oneis an adaptation of the DPI algorithm [4] that develops the tree ofthe 2 -optimal interpretations without any backtrack due to a failure.Indeed, the weight of the nodes can be used to perfectly determinewhether an branch is optimal or not. The sketch of algorithmsthat follows is a simplified version that assumes that at most oneconstraint of = restricts a given variable .function optimal(— , —ºF )(Ó è 3L—Ý5 3L—Ý5'6ÀÓ è 3L—ºFL5 3L—sFp5 return )Develop(Æ procedure ‹pÆÙ

îîrr4.5 ù Computing ñ the -optimal restorationsThe automaton also allows the determination of the 2 -optimalrestorations of a unary constraint x : they correspond to the cheapestpath among those that go from to and that support x .If the user is interested in a unique restoration of a set of valuesfor a variable , it is sufficient to find, among those supporting ofthese values, an edge 3L— — F 5 that minimizes ÓÔ33L— — F 55 . Then the corresponding2 -optimal restoration is obtained going backward from— to and then forward from —ºF to through an optimal path, thanksto the following property:Proposition 13 A path ¾ from to that contains 3L— Ï—ºFm5 is of minimalweight among the paths from to that contains this edge iff:ú?3aûÝûFL5/^U¾ – ‰lŠ+ÅŒ3aûFm5/ÞP‰lŠ+Å 3L—Ý5 s.t. Ó è 3aûFp5;ÀÓ è 3aûº5,ú?3aûÝû F 5/^U¾ – ‰lŠ+ÅŒ3aûº5'üo‰lŠ+ÅŒ3L—l5 s.t. Ó 3aûº5;ÀÓ 3aû F 5,`?3aûÝûFp5`?3aûÝÏû F 5The computational cost of a unique 2V optimal restoration is thusbounded by the size of the automaton. Again, a judicious choice ofthe encoding of the automaton can lead to an implementation of thiskind of algorithm that is bounded by the number of transitions thatsupport x plus the product of the number of variables by the maximalnumber of successors of a state.Now, in order to compute all the 2V optimal restorations of x ,we will re-use the principles presented in the previous section. Theidea is to mark, among those supporting x , all the edges 3L—Œ— F 5 thatminimize ÓÔ33L— — F 55 . The optimal paths can then be marked usingproperty 13. It is then possible to reuse any of the methods of Section4.4, rolled not on all the automaton but on the marked paths only.The worst computational cost for the generation of all the 2 -optimalrestorations is again polynomially bounded in the size of the result.5 ConclusionSeveral authors [9, 7, 11] have proposed to extend the CSP frameworkso as to handle configuration problems - the extension dealingmainly with the difficulties that are inherent to the structuration ofthe problems. The handling of another characteristic of configurationproblems, namely their interactivity, has prevailed on us to extendthe framework in another direction and to define ”Assumption-basedCSPs”. This led to an extension to non boolean domains of classicalnotions of propositional logic, e.g. nogoods, interpretations, explanations,etc.The request associated with this generalization of ATMS obviouslycorresponds to problems that are highly combinatorial. Froma practical point of view, our approach is to transfer this cost on anoff-line pre-computation: the system works on a compilation of theCSP under the form of an automaton (the size of which can itself beexponential in the worst cases) but uses algorithms that are really efficienton this structure (polynomial in the size of the result). The waywe use the automaton is close to the use of OBDD-like structuresin the handling of prime implicant/implicate and interpretations ofa boolean formula (see [8], for seminal works, and [5][3] for someapproaches very similar to ours ).Our approach takes advantage of the fact that, in configurationproblems, only a small set of constraints is subject to dynamicity,and that these constraints are unary. It relies on the fact that the componentsof configurable products can be described concisely by automata.The structuration of complex products into sub-componentsshould now help in reducing the space needed to handle the configurableproduct. The next step of our research is to thus combine therepresentation by automata with composite CSP.The principles proposed in the present paper have been implementedand tested on a preliminary benchmark coming from a realapplication in configuration: the size of the automaton is very small(about 4675 states + edges for a problem allowing 936 000 solutions),its updating and the handling of the requests is immediate (less than2ms). We are presently encoding a bigger real example (about 200variables). However, we will also have to face the definition of anexperimental protocol for the evaluation of our work, that, even lessclose to real problems, could enlighten statistically the feasibility orthe limits of the approach.Finally we did not present algorithms dedicated to the computationof explanations and nogoods since this kind of information is generallyless attractive than the notions of restoration / interpretation inthe context of a configuration task 4 , unless the number of explanationsis small and the number of restorations great: in this case, itwould be interesting for the user to build the restoration himself byselecting one constraint in each explanation. Anyway, the computationof nogoods and explanations can attractive for other potentialapplications of A-CSP. If we accept to relax the requirements of minimalityand of completeness, an efficient approach to the generationof such information could take advantage of the justifications maintainedby dynamic filtering algorithms like DN-AC4,6.REFERENCES[1] C. Bessière, ‘Arc-consistency for dynamic constraint satisfaction problems’,in Proc. of the AAAI-91 conference, pp. 221–227, (1991).[2] C. Bessière, ‘Arc-consistency for non-binary dynamic csps’, in Proc. ofthe ECAI 92, ¼ýþLÿ European Confernce on Artificial Intelligence, pp.23–27, (1992).[3] Fabrice Bouquet and Philippe Jégou, ‘Solving over-constrained csp usingweighted obdds’, Over-Constrained Systems, LNCS 1106, 293–308,(1996).[4] T. Castell, ‘Computation of prime implicates and prime implicants by avariant of the davis and putnam procedure’, in Proceedings ICTAI’96,pp. 428–429, (1996).[5] Claudette Cayrol, Marie-Christine Lagasquie-Schiex, and ThomasSchiex, ‘Nonmonotonic reasoning: from complexity to algorithms’, Annalsof Mathematics and Artificial Intelligence, 22(3-4), 207–236, (may1998).[6] R. Debruyne, ‘Arc-consistency in dynamic csps is no more prohibitive’,in Proceedings of the eighth International Conference on Tools WithArtificial Intelligence, pp. 299–306, (1996).[7] S. Mittal and F. Frayman, ‘Dynamic constraint satisfaction problems’,in Proceedings AAAI’90, (1990).[8] J.C. Madre O. Coudert, ‘A logically complete reasoning maintenancesystem based on a logical constraint solver’, in IJCAI’91, pp. 294–299,(1991).[9] Daniel Sabin and Eugene C. Freuder, ‘Configuration as composite constraintsatisfaction’, in Artificial Intelligence and Manufacturing ResearchPlanning Workshop, AAAI Technical Report FS-96-03, (1996).[10] Mihaela Sabin and Eugene C. Freuder, ‘Detecting and resolving inconsistencyin conditional constraint satisfaction problems’, in Proceedingsof the AAAI’99 Workshop on configuration, (1999).[11] Timo Soininen and Ester Gelle, ‘Dynamic constraint satisfaction inconfiguration’, in Proceedings of the AAAI’99 Workshop on configuration,(1999).[12] Gérard Verfaillie Thomas Schiex, Hélène Fargier, ‘Valuated constraintsatisfaction problems : hard and easy problems’, in IJCAI95, pp. 631–637, (1995).[13] N. R. Vempaty, ‘Solving constraint satisfaction problems using finitestate automata’, in American Association for Artificial Intelligence(AAAI’92), pp. 453–458, San Jose, (1992).Their main interest is generally ... the deduction of restorations/interpretationsby an operation of Hitting set, whereas the direct calculusis generally cheaper12

¢Dealingwith Uncertainty in Designand ConfigurationProblemsEric Bensana andTaufiq Mulyanto and Gérard VerfaillieAbstract. Design is an activity that translate a set of requirements ina feasible product by considering constraints coming from physics,technology avaibility and designer preferences. Configuration is aspecial case of design in which the product component properties arealready predefined. In this paper, the design of a new concepts (orthe validation of existing ones) is considered as a configuration problem.In the first part of this paper, we present a generic approach forconceptual design, the earliest phase of design, combining the constraintsatisfaction formalism and the object-oriented framework. Inthe second part, we introduce an approach to deal with uncertaintiesmostly found during the conceptual design phase. The proposed approachis very easy to implement and guarantees the upper bound ofthe solution existence probability. The designer can now make his orher decisions not only based on the product performance, but also onthe risk associated to that performance.1 IntroductionDesign is an activity that translate a set of requirements in a feasibleproduct which can best satisfy the realization constraints comingfrom physical phenomenas, the technology availability and designerpreferences.Configuration is a specific task of design. We can see a configurationtask as a design of a product given a set of components (possiblysizable) described by a fixed set of properties including informationson the interactions within components. In this paper we restrict thedesign context in a configuration task.A concept or a product is a solution of a configuration problemas a result of a product instantiation. In this paper, we are interestedat a system to aid designer in the configuration task using a genericapproach.Our prior internal studies related to the design and sizing of sensingsystems [3, 2] showed that the CSP framework [12] offers:a flexible approach by a natural problem representation using constraints;¡¡a context free application including an absence of domain typerestrictions.CSP framework is defined by a set of variables, a set of domainseach associated to one variable and a set of constraints allowing valuescombinations within a sub set of variables. Domains can be of alltypes: symbolic or numeric, discrete or continue. Constraints can beextensively defined (list of allowed/prohibited value combinations) orONERA/DCSD, 2 av. E. Belin, BP 4025, 31055, Toulouse, France, email:{bensana,mulyanto,verfaillie}@cert.frintensively defined (relation such as equation). Further, a representationframework such as an object-oriented framework would enhancea design problem representation. We based our proposed generic approachon these two frameworks.The generic nature of the proposed approach injures consequentlyits computing power, which limits its use for the conceptual design.More advanced phase, such as detailed design, specially in the aircraftdesign domain, is the realm of parametric optimization [10, 15]even if non classical optimization techniques such as genetic algorithmscan be used [1].Based on the CSP point of view, a number of frameworks havebeen proposed to deal with configuration problem.The Dynamic CSP framework [14] extends the classical CSPframework to deal with a situation in which the solutions do not needto have the same variables and neither to satisfy the same constraints.The idea is to associate to each variable and each constraint two possiblestates: active and non-active. States control is done by a set ofactivation constraints.The Composite CSP framework [19] answers to the same case asprevious extension but avoid the use of activation constraints. Theidea is to allow a variable to have a sub problem as a value.The frameworks represented in [17, 22] propose two steps of resolution.The first step consists of determining the final product architectureand the second consists of resolving the corresponding classicalCSP problem given the product architecture.One of the characteristics of design activities, specially during theearly stage is the existence of imprecision and uncertainty factors inthe problem model and in external input [6, 21]. None of the previousframeworks offers a technique allowing a designer to take into accountthis uncertainties in his decision making. However, we can findin [13, 18] a probabilistic approach based on Monte Carlo methodwhich is time and resource consuming.In this paper we propose an approach to deal with uncertaintybased on CSP framework which guarantees an upper bound of solutionexistence probability. Our discussions are focused on two points:1. A description of the generic approach to help designer to structurethe design knowledge of a product being considered; this knowledgeis expressed in a generic model which is used to generateconcepts;2. A proposition of an approach to deal with uncertainty which guaranteesan upper bound of solution existence probability; we willshow by a case example how this measure could be an importantelement of decision.13

.As we are applying the proposed approach in aeronautical domain,examples found in this paper will be on aircraft design problems.2 Presentation of the generic modelOur generic approach to deal with configuration problem is basedon generic model of the product being designed. The generic modelcombines two frameworks:CSP framework with the notions of variables, domains and constraintsto formalize the configuration¡¡problem;Objet-oriented representation with the notion of objects, attributes,classes, instances and inheritance to structure the configurationknowledge.2.1 The configuration knowledgeConfiguration knowledge, usually related to a given design domain,is structured in classes following an object-oriented representation.Here, a class can be seen as a template of an item. An instance isbuild upon class description corresponding to an item (final productor a product component).The five first types introduce direct choice points since they alllead to a finite set of possibilities. The last type may also lead tochoice points but only when interval splitting is considered. The inheritanceproperty will apply every attribute of a class to its specializations.For example, the class associated to a wing may has:attributes describing wing geometry in real¡numbers: wingand _ , etc.;£¥¤§¦©¨¨attributes determining wing components: flaps, slots, etc.¤¨ £¦© ¡Generic constraintsGeneric constraints are expressed at the class level. They definerelationships between:the values of some attributes of the class; as an example,¡the threegeometric attributes of a wing and _ are¤¨#related by the constraint: _ £$¦©" ¤§¨#%$&'(¨)+*©,-£¤¦©¨ £¦!" ¨ £¤¦©¨the values of the attributes of some of its components; for examplethe relation between the wing mass with the mass of¡its/_ ##¨10 _2¨(!3&/¨1!46507¨!¨1§4components:.2.1.1 Classes as generic design knowledgeThe knowledge about items is modeled by classes. Typically thereis a class for the final product and classes for its components (andrecursively). A class can be:abstract (instances cannot be built upon directly);¡generic (e.g. sizeable component, instance can be built upon, its¡exact size is not¡predefined);non sizeable (only existing instances of this class are taken intoaccount during the product instantiation).In the implementation we have two types of constraints as follows:pre-instantiation constraints help to prune the search space and¡avoid to consider wrong options during the product instantiation;there is only a small number of constraints which can be expressedin this way depending on the structural choices for an¡instance;post-instantiation constraints are used to verify the instance’s attributesconsistency during the product instantiation.Using the inheritance properties, all of constraints in a class arealso applied to all of class specializations._2_2_2©07¨1Simple inheritance is considered, i.e. a class has only one motherclass.A class is described by a set of typed attributes.AttributesEach attribute is characterized by a definition (mainly its nameand type). The domain of values associated with a variable dependson the attribute type. Our system allows the following types:oneof(List): List is a list of elements of any discrete type¡(number, atom, string, etc.) and the value can be any element of¡List;oneof(Min,Max): Min and Max are two integers, and thevalue of the variable can be any integer belonging to the [Min,Max]¡interval;instance(Cl1): Cl1 is a class name and the value can beany instance of any subclass Cl2 of Cl1 if Cl1 is abstract or aninstance of Cl1 if¡not;instance(List): List is a list of classes name and the valuecan be any instance of any class in List;instances(Min, Max, Cl) : Cl is a class name and the¡value can be any collection of instances of the class Cl whosecardinality belongs to the interval¡[Min,Max];interval(Min,Max): Min and Max are real numbers and thevalue can be any subinterval of the interval [Min,Max].2.1.2 Instances as componentsThere are two types of instances:generic instances resulting directly from the instantiation of¡classes using the product¡instantiation;instances modeling existing components or Components On TheShelf (COTS) where all of the attributes have a fixed value (atleast those describing its structure); these instances are recordedin a base of components.After a product instantiation of an item represented by a genericclass may result in a generic instance or a component in COTS. But,an item represented as non sizeable class can only be instantiatedin one of a component in COTS. COTS can be used to perfectlyrepresent the components non-customizable. In aircraft design, theengines are usually considered as COTS.2.1.3 Specific constraints as designer’s modelA model is associated to the class to be instantiated. It determinesa set of basic restrictions expressed in unary constraints. The constraintsdefined in a model takes into account the design requirementsand the designer preferences.A model describes:14

2222the requirements imposed to the product or its components; in civil¡aircraft design domain, a requirement can be the typical aircraftflight mission, aircraft capacity,¡etc.explicit designer preferences, such as a simple trapezoidal wingplan-form or door type selections.2.2 The synthesis functionThe second main part of our system is the synthesis function. Thisfunction is in charge of the product instantiation i.e. to instantiatethe class corresponding to the product using the available knowledgeand product model. Here, we find the connection between CSP formalismand the object-oriented problem representation. During theinstantiation of a class, a variable is associated to each attribute. Aninstance can be considered as a set of variables.A synthesis function can be expressed as below:It builds a set of instances of the class B$07¨1! , with:8 +9#¨:-¦&'9;?@?@ ¨ ¡CF§D¦!0 ¡¨A"B$07¨1!"C'D¦!0="B: the set of classes in generic knowledge;: a set of constraints which represent the designer preferencesand design requirements;: a set of re-used components in COTS.¡ BThe last two entries can be empty. When both are empty, onlygeneric instances will be considered. Other parameters have been definedto limit the search to the first solutions or within a time limitand to use different levels of constraint propagation.The set of available classes and COTS implicitly describes theproduct instantiation search space. Techniques utilized to explorethe search space in synthesis function are basically tree search andconstraint propagation techniques. During the product instantiation,search in the synthesis function takes into account:design choices expressed in class descriptions: choice of a class¡among several possibles classes defined in a domain attribute,choice of a component in COTS, finite domain attributes,¡etc.the choice between reusing an existing component in COTS orbuilding a new generic one;other choices related to the management of propagation over intervals.¡Depending on the component set and the model, the same synthesisfunction can be used to:validate an existing concept using only non-sizeable classes; this¡can be interesting to verify weather a proposed configuration satisfythe product¡requirements;define new concepts : generic classes are authorized and the set ofcomponents is reduced to the set of COTS.2.3 ImplementationWe chose a constraint programming language to be our supportinglanguage. The continuous domains is useful to express the sizeableproperties on an item. Two languages, although not fully equivalentare selected: Prolog IV [4] and Eclipse [8]. In our observations,Prolog IV is more powerful than Eclipse in terms ofconstraint propagation mechanism, but is much slower as far as puresearch is concerned.!EThe approach combining constraints and objects bears some similaritieswith the idea implemented in the Claire language [11, 7](notions of parameterized class, abstract class, set type attribute etc.).But as Claire does not provide, presently, constraints over real intervals,this option has been discarded. In our opinion, it is easierto add basic object-oriented features adapted to our needs in an existingconstraint programming language than to develop an efficientconstraint propagation mechanism over an existing object orientedlanguage.To avoid a premature choice between any constraint programminglanguage, we defined a kind of meta-language to express:generic constraint expressions;¡generic predicates defining classes and attribute;¡generic predicates accessing attribute values;¡generic predicates to control the product instantiation process.¡Both constraint programming language chose do not support agraphical interface. To overcome this disadvantage, web-based utilitiessuch as Netscape, HTML, Javascript, Perl/CGI and Wais areused.The resulting system, still under improvements, was used for thecivil aircrafts design studies [16]. It is currently used for a design ofHigh Altitude Long Endurance Unmanned Aerial Vehicles (HALEUAVs) [5].UAVs design is an interesting domain for configuration since anUAV can be more or less tailored for the application dependingmainly on the type of sensors to be loaded and the flight missioncharacteristics (range, endurance, altitude, etc.).The current UAV domain is organized such that different aircrafttypes can be considered: classical configuration plane, flying wing,airplane with a canard wing, etc. Different propulsion systems are described: piston engines, turbojets, electric motors with solar arraysor batteries, fuel cells as well as different types of sensors : electroopticalcameras, synthetic aperture radars, spectrometers, data transmissionrelays. This domain can be easily extended by filling up thedomain knowledge by other classes including more general classes.2.3.1 A small exampleLet be the domain considered consists of the following classes:propulsion::[[engine,instance(engine)],[nb_engines,oneof(1,2)]].engine::[[consumption,interval(0.0,10.0)]].turbomachine(engine)::[[thrust,interval(0.0,100.0)],[bypass_ratio,interval(1.0,10.0)]].turbojet(turbomachine)::[[thrust,interval(0.0,10.0)],[bypass_ratio,1.0],[consumption,interval(0.0,8.0)]].turbofan(turbomachine)::[[thrust,interval(0.0,50.0)],15

[consumption,interval(0.0,5.0)]].piston_engine(engine)::[[power,interval(0.0,100.0)],[r_propeller,interval(0.7,0.9)],[d_propeller,interval(0.0,3.0)]].abstract([engine, turbomachine]).We suppose that the engine and turbomachine classes areabstract. turbomachine and piston_engine are classes resultingof a specializations from the class motor and turbojetand turbofan are specialized class from the class turbomachine.A specialized class is allowed to have a refined attributesdomains from its motherclass as for the class turbojet.Without any specific constraint, six solutions are built by the synthesisfunction: s-1, s-2 with turbojet, s-3, s-4 with turbofanengine and s-5, s-6 with piston engine.s-1::[[engine,tj-1],[nb_engines,1]]s-2::[[engine,tj-2],[nb_engines,2]]s-3::[[engine,tf-3],[nb_engines,1]]s-4::[[engine,tf-4],[nb_engines,2]]s-5::[[engine,pe-1],[nb_engines,1]]s-6::[[engine,pe-2],[nb_engines,2]]with the components:{tj-1,tj-2}::[[consumption,[0.0,0.8]],[thrust,[0.0,10.0]]]{tf-3,tf-4}::[[consumption,[0.0,0.5]],[thrust,[0.0,50.0]]]{pe-1,pe-2}::[[consumption,[0.0,10.0]],[power,[0.0,100.0]],[r_propeller,[0.7,0.9]],[d_propeller,[0.0,3.0]]]If we add a constraint at the motorisation stating that if twomotors are considered, they can be only turbojets,not((M.nb_engines = 2),((M.engine.class = turbofan);(M.engine.class = piston_engine)))the previous solutions s-4 and s-6 will not be built because theywill not be consistent.3 Dealing with uncertaintyAfter presenting our system in the previous section, in this section wedescribe our approach to deal with uncertainty in conceptual design,the earliest phase in design activity. We based our proposed approachon CSP framework. We begin by observing two kinds of variablenatures.While representing a design problem as a constraint satisfaction orconstraint optimization problem, all the variables do not represent thesame thing. Some of them represent possible designer choices. Onesays that they are controllable. Some others represent uncertainty orimprecision. One says that they are uncontrollable. But such a distinctiondoes not exist in the standard CSP framework. Both are dealtwith the same way.There are at least two extensions of the CSP framework that aimat dealing with uncertainty:Probabilistic Valued-CSP [20] associates with each constraint¡(or each combination of values) a probability of existence in thereal world (or probability to be forbidden in the real world). Theobjective is then to find an assignment for all the variables thatmaximizes its probability to be solution in the real¡world;Mixed-CSP [9] explicitly distinguishes controllable and uncontrollablevariables. The objective is then to find an assignment forall the controllable variables that is a solution whatever the assignmentof the uncontrollable variables is. But, if a probabilitydistribution is available on the domains of all the uncontrollablevariables, the objective can be, as in the Probabilistic Valued CSPframework, to find an assignment for all the controllable variablesthat maximizes its probability to be solution in the real world.Both extensions only differ in the way of expressing uncertainty:in the first framework, uncertainty is associated with constraints orcombinations of values, while variables and domains are the sameas in the standard CSP framework; in the second framework, uncertaintyis associated with values of uncontrollable variables, whileconstraints are the same as in the standard CSP framework. At leasttheoretically, any problem expressed in one of the above frameworkscan be expressed in the other.To deal with uncertainty in design problems, we choose the secondframework based on the distinction between controllable and uncontrollablevariables. Using the generic model presented previously:1. we express this distinction in the definition of the classes; then anyvariable involved in a design problem is either controllable, or not;it suffice to state weather an attribute is controllable or not;2. we use this distinction to provide the designer with useful informationabout the consistency probability of the current problem.We will see that such an extension does not imply any change neitherin the generic model, nor in the synthesis function presented above.3.1 Controllable variablesHere, controllable means that the assignment of a value to the variableis under the control of the designer. We can distinguish threetypes of controllable variables:design variables: they physically describe the designed product; in¡the example of section 3.4, the attributes representing wing span,the wing area, the lift coefficient, and the aircraft drag due to surfacefriction are all design¡variables;evaluation variables: they characterize the performance of the designedproduct; in the same example, the attribute lift-to-drag ratiois an evaluation¡variable;intermediate variables: they are used to simplify the problem expression;still in the same example, the aspect ratio AR is an intermediatevariable.3.2 Uncontrollable variablesOn the contrary, uncontrollable means that the assignment of a valueto the variable is not under the control of the designer. This may bedue to the presence of:16

imprecision or uncertainty in the available design knowledge i.e.¡in item model expressed in¡classes;imperfectly known environment factors; some inputs maybe impreciseor uncertain;¡other designer decisions in a distributed design context.3.3 Proposed approachWe make the following assumptions:uncertainty can be modeled as a probability distribution on the¡domain of each uncontrollable¡variable;all the uncontrollable variables can be considered as independent.Using the constraint propagation mechanism, during the productinstantiation, controllable variable assignments are propagated in thewhole problem and may induce domain reductions on the uncontrollablevariables. The smaller the size of the current domains of theuncontrollable variables, the smaller the probability of existence ofa real solution in the current problem. We simply propose to use thesize of the current domains of the uncontrollable variables to computean upper-bound on the probability of existence of a real solutionin the current problem.More formally, a BGAHI&J>%KL ?M"H$¤§B$NLE is defined:is the set of con-is the set of uncon-KO&P>%K$3QRKGSEwhere KGT&VU©W ¢ 9XYXYXYW-Z[¡trollable variables, and ¢ 9XYX^XY(WS_\[K\S]&IU!WStrollable variables ;?`&a>?@AQb?@SEwhereXYXYX D9Z, is the¡ ¢ed d domainassociated ¢1d XYX^X d DS _with , , and is the domainassociated with ?@&cD D-f W-f ?@S]&cDS DSg 9XYXYXYi_$[;where is, for each uncontrollable variable,g i g ¢ H$¤$&hU©i WS ¡¡ Bthe probability distribution associated with ;a set of constraints, each of them involving at least one controllablevariable;DSg :, whereNj&lk _gm ¢ N g ¡i g >vEX Dv r§st!ufor continuous domains, andN g&n5o>pDS g i g Efor discrete domains.g i g Eq& 5o>pDSg i g Ej& 5o>pDShas good aerodynamic properties by considering the wing geometryuncertainty. In this example the wing placement is represented by thelift coefficient variable.Here, we consider two sizeable components : aircraft componentand wing component, where the wing component is a subpart ofaircraft component. Below, we define the wing and aircraftclasses.The wing class has the following attributes:wing span: span¡wing surface: area¡wing Oswald factor: oswald¡The Oswald factor is a parameter representing the lift distributionalong the wing. It is affected by many other specific wing parameterssuch as twist angle distribution and wing airfoil distribution. In theearly stages of design, this information is not available. One can considerthe Oswald factor as an uncontrollable variable taking its valueover a given interval. In this example, we take an interval between0.7 and 0.8. There is no constraint in the wing class definition.The aircraft class has the following attributes:aircraft aerodynamic property represented by the lift-to-drag ratio:¡¡lift_to_dragaircraft lift coefficient: c_liftaircraft total drag coefficient: c_drag¡aircraft surface friction drag coefficient: c_drag_fr¡aircraft wing component: ac_wing¡The aircraft class contains constraints between these variablesand the variables in the wing class. In this example we assume thatthe surface friction drag coefficient does not depend on the wing geometryvariation.wing::[[span, interval(0.0,10.0)],[area, interval(0.0,20.0)],[unc(oswald), interval(0.7,0.8)],[alpha, interval(0.0,1.0)]].wyx!z s-t!u i g >v{EUnder the independence assumption, N is an upper-bound on theprobability of existence of a real solution in the current problem. Ifwe make the following assumptions:for each uncontrollable variable, the probability to take its value¡in its initial domain (before synthesis, i.e. before constraint propagationand tree search) is equal to¡1;for each uncontrollable variable, the associated probability distributionis uniform.fis simply the ratio between the size of the current domainNfofand the size of its initial domain. is consequently very easy to|compute at any step of the N synthesis.Moreover, by associating each uncontrollable variable with oneitem (product or component), such an approach can be easily integratedin the object-oriented framework.3.4 A problem exampleWe take an example of UAV design for cruising flight. The designerhas to determine a wing placement with regard on aircraft body thataircraft::[[lift_to_drag, interval(0.0,20.0)],[c_lift, interval(0.0,1.0)],[c_drag, interval(0.0,1.0)],[c_drag_fr, interval(0.0,1.0)],[ac_wing, instance(wing)],[alpha, interval(0.0,1.0)]].The predicate unc(X) defines X as an uncontrollable variable.The following constraints are expressed at the aircraft level:aircraft_constraints(Aircraft){Wing = Aircraft.ac_wingSp_2 = power(Wing.span, 2.0)AR = div(Sp_2, Wing.area)Cl_2 = power(Wing.c_lift, 2.0)E = Wing.oswaldK = product(pi, AR, E)CDi = div(Cl_2, K)Wing.c_drag = plus(Wing.c_drag_fr, CDi)}17

Aircraft is a variable representing the current instance beingbuilt, power, div, plus, product belong to the set of basic constraintsdefined in the language and pi refers to the value of i .Let us assume now that the designer has set some controllable variablesand expressed his preferences (in IU metrics) in the followingaircraft model:Aircraft.ac_wing.span = 6Aircraft.ac_wing.area = 4.2Aircraft.c_drag_fr = 0.02Aircraft.c_drag

¡¢Preference-based Configuration of Web Page ContentCarmel Domshlak Samir Genaim Ronen BrafmanAbstract. In this paper we present a new approach for personalizedpresentation of web-page content. The model is defined as apreference-based configuration process that is based on qualitativedecision theory. This configuration process attempts to determine theoptimal presentation of a web page while taking into account thepreferences of the web author as well as viewer interaction with thebrowser. The preferences of the web-page author are represented bya CP-network, a graphical model developed in [2]. We present animplementation of our approach in a CPML system and discuss theimplementation issues.1 INTRODUCTIONAn important goal for web-page designers is the ability to provideviewer oriented personalization of web-page content. Two approachesto this problem are currently in use: (1) Learning user profiles;(2) Online information gathering by shared keywords. Both approachesare useful in particular applications, but as general solutionsthey have some important drawbacks: The first approach addressesonly long-term user preferences, and therefore, it is only applicableto frequent viewers. In addition, it reacts slowly to shifts in userinterests. The second approach uses keywords that show up in thematerial the user requested as a basis for fetching and presenting additionalinformation that may also interest the user. This approach ismore dynamic in that it reacts immediately to changes in the user’sinterests. However, the web-page designer has little, if any, controlover the content of different web-page components.In this work we propose a new model for representing the contentof a web-page. This model reflects the preferences of the web-pageauthor while adjusting dynamically to the viewer’s current interests.First the web-page author expresses his expectations regarding thepresentation of the web-page content. For example, the author mayprefer some material to be fully presented if and only if the headingof some other material is presented. This is done in an intuitiveyet expressive manner. These expectations become a static part ofthe web document, and set the parameters of its initial presentation.For any particular user, the actual presentation then changes dynamicallyto accommodate that user’s choices and actions. We achievecontent personalization through dynamic preference-based reconfigurationof the web page. Note that a web page is usually composedof a collection of components, and the information content of eachcomponent can be presented in different ways. For example, an articlecan be presented by its heading, summary, by partial content,or by the full content. The content’s configuration process attemptsto determine the best presentation of all web page components withAll authors are from Department of Computer Science, Ben Gurion Universityof the Negev, P. O. Box 653, Beer-Sheva 84105, Israel, e-mail:@cs.bgu.ac.ildcarmel,brafman,genaim£respect to the web-page author’s preferences and the viewer’s behavior.Our approach is based on qualitative decision theory, and we arguethat it provides appropriate support for web page configuration.We use the CP-network model [2] to represent the web-page author’spreferences. A CP-network is a qualitative, graphical model of preferences,that captures statements of conditional preferential independence.We implement this approach in the framework of the CPMLsystem, which consist of the authoring tool for the preference-basedweb pages, and a corresponding viewing tool, which is implementedas a browser plugin.The paper is organized as follows: In Section 2, we present theframework of the web page preference-based configuration in thecontext of qualitative decision making. We then discuss the relevantpreference representation issues, and describe the CP-networkmodel. In Section 3, we describe the architecture and implementationof the CPML system. In Section 4, we summarize the presentationand discuss future work.2 PREFERENCE-BASED WEB PAGECONTENT PERSONALIZATIONIn this section we present preference-based web page configuration,and show how decision theoretic tools provide a basis for this application.General preference-based configuration was previously investigated[1, 3, 4], however its adaptation to information personalizationhas not been explored.In preference-based configuration, a decision maker chooses anumber of different components, that together form the final product.The chosen configuration should be the best (or at least an undominated)configuration with respect to the decision maker’s subjectivepreferences. The whole process of a partly unsupervised, preferencebasedconfiguration can be divided into three stages:1. an identification step, which consists of selecting relevant criteria,2. a specification step, which consists of interactive elicitation of userpreferences,3. a processing step, which consists of reasoning about componentselection with respect to the user’s preferences,Note that the user alluded to in stages 2 and 3 is the web-pagedesigner. Here we describe a preference-based configuration of theweb page content. We first provide a formalization of this problem,then we discuss the preference representation issues.2.1 Configuration and qualitative decision theoryA web page consist of a finite set of components ¤¦¥§¤ ¡©¨¨ ¤ ,each one with an associated finite domain of component values,. For example, the components can be articles, © ¨©¨ ¡¥19

!!¤:

cbccdb¨bdbbbdbc+pages.3 CPML SYSTEM DESCRIPTIONCPML is a prototype system currently being developed at Ben-Gurion University for preference-based authoring and viewing of interactiveweb pages. The outline of the system is presented in Figure2. The system can be divided into two modules - the authoring tool,and the viewing tool.The authoring tool allows web-page authors both to create a webpage, and to define preferences on the values of its components.The first task is standard for web-page authoring tools. However,in CPML it is adapted to make subsequent definition of preferenceseasy to the web-page author. The content of the web pagesis described in dynamic HTML (DHTML) [7]. It consist of HTMLblocks, which are wrapped by javascripts, to allow presenting theircontent in different manners. The second task is defining a CPnetworkthat captures the preferences of the web-page author on theconfigurations of the web page. The editor for CP-networks is integratedin the authoring tool, and tightly coupled with the web pagecreation process. During the creation of the web page, all its componentsare tagged, thus can be declared as variables in a correspondingCP-network.Authoring ToolUWVYX Z\[,]Y^ RSTX [*] VY_a`DHTMLCP-netdescriptionWebBrowserPluginAgentResponse(¤Procedure )var:- CP-network of the web page’s components- List of the events (component, value) produced by the viewer1. Switch the value of ¤and add it to the chronologically sorted eventlist c . If c is bigger than a specified threshold: remove the oldestevent from c .2. Set to the optimal configuration returned by BestConfiguration)( ¨Procedure BestConfiguration ( c ¨ cbedb ¡ "d¨¨ db db b f=1. Reduce graph to by projection of on it, and letbe the connected components of2. For each , and for each variable (according to a topolog-andical sort) set f to its most preferred value with respect to ' (gfFigure 3.)Preference-based reactive configuratorof the recent viewer’s choices. The maximal size of is specifiedby the author of the web page and is passed as a part of the document.Subsequently called procedure BestConfiguration performs the optimizationand returns one of the pareto optimal configurations, consis-ctent with the preferences of the web-page author ( ), and the recentchoices of the viewer ( ). Due to the semantics of the CP-networkmodel, this process can be performed in time linear in the numberof components. For details about the optimization procedure consultc[2].4 SUMMARY AND FUTURE WORKFigure 2.Framework of the CPML systemCP-network driverThe client side consists of a standard browser expanded by aCPML agent, implemented by a browser-compatible plugin. Accessinga web document in our system results in shipping the documentto the browser and the embedded CP-network to the agent. On thedownload of a preference-based web document, the agent sets all thecomponents to their corresponding values in the optimal configuration,given no evidences on the viewer’s current interests. From thispoint the agent acts in event-driven fashion, and waits for a viewer interactionwith the browser (exposing/hiding a component). The agentis responsible to react to the viewer’s actions by changing the contentpresentation of the document. The change is performed according tothe embedded CP-network and the recent actions of the viewer. Thebest configuration of the web page, given the recent choices of theviewer, is determined, and the web page is redrawn.Determining the best configuration is done by the procedure AgentResponse,presented in Figure 3. At this current stage of the systemdevelopment we restrict ourself to components with only binarydomains in order to exploit significant computational benefits, describedin details in [5]. Therefore, in step 1 of AgentResponse, weswitch the value of the observed component, and then add it to the listIn this paper we presented a framework for preference-based configurationof the web page content. Our approach is based on qualitativedecision theory, and in particular on the CP-network graphicalmodel for preference representation. The configuration processis performed according to the preferences of the web author as wellas to the current interests of the viewer. Preferences of the web-pageauthor are encoded as a CP-network. Given this CP-network and therecent actions of the viewer, the optimal configuration of the webpage content is determined.A prototype implementation of the CPML system is currently beingdeveloped, and we plan to complete it by August 2000. It consistof an authoring tool on the web-page author’s side, and the decisionmaking agent on the client side, implemented as a browser plugin.In addition, we are implementing an overall solution that is based onJava applets instead of plugin.REFERENCES[1] C. Boutilier, R. Brafman, C. Geib, and D. Poole, ‘A Constraint-BasedApproach to Preference Elicitation and Decision Making’, in AAAISpring Symposium on Qualitative Decision Theory, Stanford, (1997).[2] C. Boutilier, R. Brafman, H. Hoos, and D. Poole, ‘Reasoning with ConditionalCeteris Paribus Preference Statements’, in Proceedings of the FifteenthAnnual Conference on Uncertainty in Artificial Intelligence (UAI–99), (1999).[3] Joseph D’Ambrosio and William Birmingham, ‘Preference-Directed Design’,Journal of Artificial Intelligence in Engineering Design, Analysis,and Manufacturing, 9, 219–230, (1995).21

h[4] D.L.Thurston, ‘A Formal Method for Subjective Design Evaluationwith Multiple Attributes’, Research in Engeneering Design, 3, 105–122,(1991).[5] Carmel Domshlak and Ronen Brafman, ‘Structure and Complexity inPlanning with Unary Operators’. (submitted to 14th Workshop ”NewResults in Planning, Scheduling and Design”, ECAI-2000).[6] J. Doyle and R.H. Thomason, ‘Background to Qualitative Decision Theory’,AI Magazine, 20(2), 55–68, (1999).[7] Jeff Rule and Jeffrey S. Rule, Dynamic Html: The Html Developer’sGuide, Addison-Wesley, November 1998.22

Exploiting structural abstractions for consistencybased diagnosis of large configurator knowledge basesAlexander Felfernig 1 , Gerhard E. Friedrich 1 , Dietmar Jannach 1 and Markus Stumptner 2Abstract. Debugging, validation, and maintenance of configuratorknowledge bases are important tasks for the successfuldeployment of product configuration systems, due to frequentchanges (e.g., new component types, new regulations) inthe configurable products. Model based diagnosis techniqueshave shown to be a promising approach to support the testengineer in identifying faulty parts in declarative knowledgebases. Given positive (existing configurations) and negativetest cases, explanations for the unexpected behavior of theconfiguration systems can be calculated using a consistencybased approach.For the case of large and complex knowledge bases, we showhow the usage of hierarchical abstractions can reduce thecomputation times for the explanations and in addition givesthe possibility to iteratively and interactively refine diagnosesfrom abstract to more detailed levels. Starting from a logicaldefinition of configuration and diagnosis of knowledge bases,we show how a basic diagnostic algorithm can be extended tosupport hierarchical abstractions in the configuration domain.Finally, experimental results from a prototypical implementationusing an industrial constraint based configurator libraryare presented.1 INTRODUCTIONKnowledge based product configuration systems are a successfulapplication of AI technology and will still gain furtherimportance due to the fact that more and more companies startto offer their products tailored to their specific customer’sneeds [4]. Many approaches for efficient problem solving andknowledge representation for configuration problems havebeen proposed, starting from rule-based systems [1] up tohigher forms of representation and reasoning techniques, e.g.,constraint based, case based, or functional reasoning([14],[18]). However, the facts that real-world configurationknowledge bases tend to get large and complex and that theknowledge bases are subject to frequent changes (e.g., newcomponent types, new regulations and restrictions) make thevalidation, maintenance, and debugging activities to importanttasks during the lifecycle of the configurator. In fact, especiallythe maintenance problem was one of the most importantproblems already in the first industrial configuration systems[1] where changes of up to fourty percent of the knowlegebase per year are not unusual.Techniques from model based diagnosis (MBD) which were1 Institut für Wirtschaftsinformatik und Anwendungssysteme,University of Klagenfurt, 9020 Klagenfurt, Austria; email:{felfernig,friedrich,jannach}@ifi.uni-klu.ac.at2 Institut für Informationssysteme, Abteilung für Datenbankenund Expertensysteme, Paniglgasse 16, A-1040 Wien; email:mst@dbai.tuwien.ac.atinitially applied to diagnose faults in electronic circuits andother hardware devices have shown to be also applicable forthe domain of software debugging, e.g., diagnosis of logicprograms [5], repairing inconsistencies in databases [12], orVHDL programs [10].In [7], it was shown, how these techniques can also be appliedfor error detection within knowledge based configurationsystems. Speaking in MBD terms, a system is composed froma set of components with some predefined behavior. A diagnosisis then a set of components from the system, which ifconsidered to be faulty, can explain discrepancies between theexpected behavior of the system and the actual observations.When employing MBD to debug faulty knowledge bases, therole of the system’s components is taken by the elements ofthe knowledge base (typically logical sentences or constraints).When provided some examples (test runs, observations)the diagnostic task is to identify these faulty parts fromthe knowledge base which explain an unexpected behavior ofthe configurator. For these task, positive and negative examplescan be employed. Positive examples are (partial or complete)configurations, which should be accepted by the configuratoror can be extended to a complete configuration.These positive examples can be former (supposedly valid)configurations, which should still be valid after some changesin the knowledge base. Negative examples are configurationswhich should be rejected by the configurator (e.g., becausethese constellations should not be available anymore). Thebehavior of the configurator is said to be unexpected if a positiveexample is rejected or if a negative example is falselyaccepted.However, when debugging large and complex knowledgebases, this diagnosis technique can be costly in terms of computationtime, especially in cases, when multiple faults ofhigher cardinality should be detected and when the explanationfacilities of the employed inference engine (e.g., a specializedconstraint solver) are limited. The usage of abstractionhierarchies with different levels of detail has been appliedsuccessfully to increase the efficiency of model based diagnosis[16]. In this paper we want to show how these abstractionmechanisms can be employed for the diagnosis of configuratorknowledge bases, where we can take advantage of the typicalstructure of these knowledge bases. Accordingly, no additionalor artificial hierarchies must be defined to allow for ahierarchical approach, where we can start the diagnosis with ata high level (with a coarse granularity) which can be calculatedvery fast, and can then iteratively refine those diagnosesto a more detailed level.The paper is organized as follows: After giving a motivatingexample (Section 2) we shortly review the definitions of consistencybased diagnosis of configurator knowledge basesfrom [7] and show how a hierarchical extension can improvethe efficiency of the algorithm (Section 3). After presentingexperimental results using a simple algorithm with an indus-23

trial strength configurator library (Section 4) we discuss relatedwork and conclusions.2 MOTIVATING EXAMPLEFor the demonstration of our approach we use a small part of aconfiguration knowledge base from the domain of configurablepersonal computers. We employ first order logic as arepresentation mechanism to provide clear and precise semantics.As a conceptual model, a component-port based approachis chosen [15], the graphical depiction follows the approachfrom [6].Motherboardm1 = {true,f alse}m2 = {true,f alse}m3 = {true,f alse}1..1PCp1 = {true,f alse}1..11..2FloppyCPUc1 = {true,f alse}c2 = {true,f alse}Figure 1 Example problemWe employ the following predicates for our logical representation:types, ports, attributes, and dom are functions to describethe component types of the domain with their connectionpoints and attributes with possible values (domain). Thefacts type/2, conn/4, and val/3 describe individual componenttype instances, their connections and the attribute valuations.We also use a logic programming notation, where variablenames start with upper-case letters.The knowledge base consists of the following definitions:types={pc,motherboard, cpu, floppy}ports(pc)={motherboard,cpu,floppy-1,floppy-2}.ports(motherboard)={pc}.ports(cpu)={pc}. ports(floppy)={pc}.attributes(pc)={p1}. attributes(cpu)={c1,c2}. ...dom(pc,p1)={true,false}. dom(pc,p2)={true,false} ....In addition, the following constraints on attribute combinationsof PC, Motherboard, and CPU have to hold:Constraint PC 1 : (p1 = m1 ∨ c1)type(P,pc) ∧ type(M,motherboard) ∧ type(C,cpu) ∧conn(P,motherboard,M,pc) ∧ conn(P,cpu,C,pc) ∧ val(P,p1,X)∧ val(M,m1,Y) ∧ val(C,c1,Z) ⇒ X = Y ∨ Z.Constraint MB 1 : (m1 = m2 ∧ m3)type(M,motherboard)∧ val(M,m1,M1) ∧ val(M,m2,M2) ∧val(M,m3,M3) ⇒ M1 =M2 ∧ M3.Constraint MB 2 : (m2 = m3)type(M,motherboard) ∧ val(M,m2,M2) ∧ val(M,m3,M3) ⇒M2 =M3.Constraint CPU 1 : (c1 = c2)type(C,cpu)∧ val(C,c1,C1) ∧ val(C,c2,C2) ⇒ C1 = C2.Note that additional constraints may be defined for the componenttypes (e.g., for the floppy type), which are omitted inthe example because they are not part of any minimal conflictset.Let us assume, that constraint PC 1 was newly introduced tothe knowledge base and contains an error and should be"p1 = ¬ (m1 ∨ c1)"If we consider the only positive example to be a configurationwith connected instances of one PC, one Motherboard, andone CPU, where p1=false, m2=true, and c2=true, more formally,CONF = {type(pc1,pc). type(cpu1,cpu).type(mb1,motherboard}.conn(pc1,motherboard, mb1,pc).conn(pc1,cpu,cpu1,pc) .val(pc1,p1,false).val(mb1,m2,true). val(cpu1,c2,true).},this partial example cannot be completed to a working configuration.The constraints {PC 1 ,MB 1 ,MB 2 ,CPU 1 } cause acontradiction with the positive examples. When applying thediagnosis algorithm from [7], the following minimal diagnosesare returned expressed using ab (abnormal) literals.ab(PC 1 ). ab(MB 1 )∧ ab(CPU 1 ). ab(MB 2 )∧ ab(CPU 1 ).In other words, if we consider- for each diagnosis - the individualconstraints to be faulty, i.e., abnormal (and ignore it inthe search for solutions) a solution to the problem can befound. The resulting diagnoses serve as pointers for the testengineer on which constraints he/she should focus the debuggingefforts. (For the treatment of negative examples, see [7]).For the calculation of diagnoses, the notion of conflict sets isused. A conflict set can be seen as a set of constraints in ourknowledge base which, together with the domain descriptionand an example, causes a contradiction. A conflict set is minimal,if no subset of the conflict set is itself a conflict set.Although the diagnostic algorithm does not rely on the calculationof minimal conflict sets, the size of the conflict setsheavily influences the overall efficiency of the task. In cases,where we do not have minimal conflict sets, the diagnosticalgorithm tries to find explanations that contain constraintswhich are definitely not relevant (e.g., some constraints on thefloppy component type in our example.) The calculation ofminimal conflict sets can also be costly, if the employed inferenceengine has only limited explanation facilities.In the following we describe an approach, where we usestructural abstraction, i.e., the system and its components isdecomposed into a hierarchy of its subcomponents. The diagnosisprocess is started at an abstract level where the model isusually very simple and consists of only a few high levelcomponents. The calculation of solutions can be done veryefficiently. When moving to the detailed level, the lower leveldetails are taken into consideration, but the detailed diagnosisis done using the results from the previous levels. In technicalsystems, the hierarchical decomposition is often given throughthe system’s physical structure. In some cases, diagnosis of thesubcomponents is not even needed, if the smallest replaceablepart is the aggregate component. When diagnosing configurationknowledge bases, the structural abstraction is giventhrough the assignment of the individual constraints to componenttypes. In other words, if we assume a component typedefinition to be faulty, we assume that all constraint typesassigned to that component type are faulty. In the followingwe only consider such a two level hierarchy, although furtherabstractions (grouping of several related component types)may be applicable. When using this abstraction mechanism,the top level diagnoses for the problem areab(PC). ab(Motherboard) ∧ ab(CPU).24

These initial diagnoses can be computed very efficiently sincewe have only four top level diagnosis components. Given thisinitial diagnosis the user can decide to focus on the PC componenttype (maybe because he/she only made changes forthat component type) or can decide to iteratively refine theresults through replacement of the component types with theirindividual constraints. In the following section we will treatthis model more formally.3 DIAGNOSIS OF CONFIGURATORKNOWLEDGE BASESFirst, we will shortly review the logical definition of configurationand configuration problems from [7]: Typically, configurableproducts are built from a predefined set of componenttypes, which are characterized through attributes and can beinterconnected via predefined connection points (ports). Thisinformation and the constraints on legal constellations can beexpressed as a set of logical sentences DD (domain description).Configuration problems have to be solved according tosome specific requirements, again described through a set ofsentences SRS. A configuration result is described by a set ofground literals containing information on the employed componentinstances, attribute valuations, and connections (e.g.,type, val, and conn - literals).Definition (Configuration Problem): A configuration problemis described by a triple (DD,SRS,CONL), where DD andSRS are sets of logical sentences and CONL is a set of predicatesymbols.DD represents the domain description, SRS an individualconfiguration problem instance. A configuration CONF isdescribed by a set of ground literals whose predicate symbolsare in CONL.Definition (Consistent Configuration): Given a configurationproblem (DD,SRS,CONL), a configuration CONF isconsistent iff DD ∪ SRS ∪ CONF is satisfiable. ¡To ensure the completeness of a configuration, additionalformulae for each predicate symbol in CONL have to be introducedto CONF, e.g.,type(X,Y) ⇒ type(X,Y) ∈ CONF.We denote the configuration CONF extended by these axiomswith CONF . (For a detailed exposition, see [7]).Definition (Valid and irreducible configuration): Let(DD,SRS,CONL) be a configuration problem. A configurationCONF is valid iff DD ∪ SRS ∪ CONF is satisfiable. CONF isirreducible if there exists no other valid configurationCONF sub such that CONF sub ⊂ CONF. ¢In MBD terms, a system consists of a set of components and aset of observations describing the actual behavior of the system.The role of the components is played by the elements ofDD, the observations are given in terms of positive and negativeexamples.Definition (CKB-Diagnosis Problem): A CKB-DiagnosisProblem (Configuration Knowledge Base) is a triple (DD,E + ,E − ) where DD is a configuration knowledge base, E + is a setof positive and E −- a set of negative examples. The examplesare given as sets of logical sentences. We assume each exampleon its own to be consistent. £Positive examples are (partial) configurations, which shouldbe accepted by the configurator, whereas negative examplesshould be rejected.Given these example sets and the domain description cause aninconsistency, a diagnosis corresponds to the removal ofpossibly faulty sentences restoring the consistency. In addition,if a negative example is consistent with the knowledgebase, we have to find an extension to DD which restores inconsistencyfor all such negative examples.Definition (CKB-Diagnosis): A CKB-Diagnosis for a CKB-Diagnosis Prolem (DD,E+,E − ) is a set S ⊆ DD such that thereexists an extension EX, where EX is a set of logical sentences,such thatDD - S ∪ EX ∪ e + consistent ∀ e + ∈ E +DD - S ∪ EX ∪ e - in consistent ∀ e - ∈ E − ¤Proposition: Given a CKB-Diagnosis Problem (DD, E + , E − ) ,a diagnosis S exists iff∀e + ∈ E + : ∪ ∧ e−∈ E - (¬ e − ) is consistent.From here on we refer to the conjuction of the negated negativeexamples as NE, i.e., NE = ∧ e−∈ E − (¬ e − ).Proof. see [7].In order to precisely define our approach of using abstractionhierarchies for the diagnosis task, we employ the concept ofTheory Diagnosis from [9]. In our example, the abstraction ofindividual constraints from the knowledge base to componenttypes comprising all assigned constraints can be expressed interms of equivalences, e.g.,ab(MB) ≡ ab(MB 1 ) ∨ ab(MB 2 ).ab(CPU) ≡ ab(CPU 1 ) ∨ ... ∨ ab(CPU n ).This equivalences express that a component type definition isconsidered faulty, if at least one of the assigned constraints isfaulty. We call this theory of hierarchical abstraction an abtheory∑.Definition (Hierarchical Theory): A hierarchical theory is aset of ab-clauses of the formab(c i ) ≡ ab(c j ) ∨ .... ∨ ab(c k ).where all literals contained in such an identity are unique.There are no two equivalences having the same literal on theleft hand side. ¥Note, that such a hierarchical theory defines a set of directedtrees. Although in our example, only two level hierarchies aredefined, further abstractions are possible, e.g., grouping ofseveral component type definitions to a package, i.e., a morecomplex substructure of the configured system. For the hierarchicaldiagnosis task, the domain description DD is extendedwith this abstraction hierarchy Σ.Let LHS(Σ) be the set of literals that appear on the left handside of a clause from Σ. In the following, given a set C ⊆LHS(Σ), we denote succ(C) as the union of the set of all directand indirect successors and leaves(C) be the union of all leafnodes of all c i ∈ C in the tree formed by the hierarchical theory.In the following, leaf constraints denote the set of allleaves of all trees and abstract constraints be the non-leafsentences.25

For hierarchical diagnosis we extend our notion of CKB-Diagnosis in a way that also constraints can appear in thediagnosis which are on the left hand side of a clause from thehierarchical theory.Definition (Abstract CKB-Diagnosis): An Abstract CKB-Diagnosis for a configuration problem (DD,E + ,E − ) and ahierarchical theory Σ is a set of sentences S from DD and anon-empty set C from LHS(Σ) such that:DD − S − leaves(C) ∪ EX ∪ e + consistent ∀ e + ∈ E +,DD− S − leaves(C) ∪ EX ∪ e - inconsistent ∀ e − ∈ E − whereS ∩ leaves(C) = ∅, ∀ c∈ C: c∉ succ(C). ¦Following this definition, such a diagnosis can therefor containindividual constraints from DD as well as abstract constraints.If an abstract constraint is considered faulty, all itssub-constraints are also considered faulty and must not becontained in S. In addition, if an abstract constraint is consideredfaulty, no abstract subconstraint according to the hierarchymay be contained in C.Definition (Minimal Abstract CKB-Diagnosis): An AbstractCKB-Diagnosis AD = {S ∪ C} for (DD, E + ,E − ) and Σ is saidto be minimal, if no subset AD’ ⊂ AD is an Abstract CKB-Diagnosis. §Similar to (Minimal) Theory Diagnoses [9], these abstractdiagnoses can be used as a generator for a set of minimal diagnoses.The abstraction theory Σ describes how the abstractdiagnoses have to be extended in order to provide minimaldiagnoses.4 COMPUTING DIAGNOSES4.1 Computing abstract diagnosesGiven the above definitions we can extend the standard algorithmfor consistency-based diagnosis to calculate minimal(abstract) diagnoses. The basic algorithm is extended to fit theneeds of our application domain and to support the notion ofstructural abstraction. In the standard algorithm ([13],[17]),the concept of conflict sets is used for focusing purposes:Definition (Conflict Set): A conflict set CS for (DD, E + ,E − ) isa set of elements from DD such that ∃ e + ∈ E + : CS ∪ e + ∪NE is inconsistent. ¨In order to support the calculation of minimal abstract diagnoses,we extend the definition of conflict sets to allow a conflictset to contain not only sentences from the knowledge base butalso abstract constraints, which are then replaced by theirsubcomponents:Definition (Abstract Conflict Set): An abstract conflict setACS for (DD,E + ,E − ) and a hierarchical theory Σ is a set ofelements S from DD and a set C from LHS(Σ) such that ∃ e + ∈E + : S ∪ leaves(C) ∪ e + ∪ NE is inconsistent, whereS ∩ leaves(C) = ∅, ∀ c ∈ C: c ∉ © succ(C).In the algorithm, the basic HS-DAG algorithm from([13],[17]) is extended as follows: a node n in the tree is labeledby a conflict set CS(n); edges leading away are labeledby elements s ∈ CS(n). The set of edge labels on the pathfrom the root to a node n is referred to as H(n). In addition, foreach node n a set CE(n) of consistent positive examples isstored, having in mind that once an example is already consistentit will not become inconsistent after further removal ofconstraints. Since a node can have multiple direct predecessors[13] - referred to as preds(n) - we combine the sets CEfrom all direct precedessors for such a node.According to the idea of iteratively substantiating abstractdiagnoses following the hierarchical structure of the problem,we will initally compute a set of high level diagnosis whichcan then be refined to a more detailed level. Consequently, thediagnostic algorithm has an additional input parameter besidethe problem description and the examples, i.e., an abstractdiagnosis that was already calculated on a higher abstractionlevel. During the calculation of a diagnosis the results fromthat higher level are reused and the diagnosis task is performedon the next detailed level, i.e., abstract constraints arereplaced by the constraints from the next lower level.Accordingly, given an abstract diagnosis AD as input, conflictsets returned by the call to the theorem prover must obeycertain restrictions. Given a set AC of abstract constraints, letsons(AC) be the set of direct successors according to the hierarchicaltheory Σ.• If AD = ∅, only sentences from the top level of the abstractionhierarchy can be contained in the returned abstractconflict set.• If AD ≠ ∅, only sentences from sons(AD), constraintsfrom the top level of the abstraction hierarchy which arenot part of the hierarchy of elements of AD, and elementsfrom AD itself, which are already at the lowest level of theabstraction theory, can be contained in the returned abstractconflict set.• The returned (abstract) conflict set cannot contain anyelements from the path H(n) from the root node of the HS-DAG to the current node.Algorithm: (schema)In: (DD,E + ,E − ), Σ, an abstract Diagnosis ADOut: a set of refined diagnoses RD(1) Use the hitting set algorithm to generate a pruned HS-DAG D for the collection F of abstract conflict sets for((DD,E + ,E − ), Σ). Compute the DAG in breadth-first mannerin order to generate diagnoses in order of their cardinality.(a) Every theorem prover call TP(DD − H(n), E + −CE(preds(n)), E − , Σ, AD) at a node n tests whetherthere exists an e + ∈ E + such that there is an inconsistency.In this case an (abstract) conflict set is returned,otherwise it returns ok.(b)Set CE(n) to be the set of examples found to be consistentin the call to TP union the examples that werealready consistent at the direct precedessors of n.(2) Return {H(n) | n is a node of D labeled by ok4.2 Computing all minimal diagnosesAs described in [9], the calculated abstract diagnoses can beused to describe all minimal diagnoses and serve as a generatorfor all these diagnoses. Following the explanations fromSection 2, we propose an iterative approach where one startswith a high level diagnosis which can be computed very efficientlyand decide afterwards either to stop at the current leveland focus on some package of sentences from the knowledgebase or to refine the diagnosis to a more concise level. Inaddition, the hierarchical approach can also be applied if the26

user only is interested in the most detailed level, because thehierarchical approach outperforms a flat approach in manycases. The recalculation of diagnoses at the different levelscauses additional costs but the resulting HS-DAG’s size ismuch smaller depending on the structure of the knowledgebase. In addition, in cases where the employed inferenceengine lacks sufficient explanation facilities (see experimentalresults) and the calculation of minimal conflict sets would becostly, the algorithm performs better than a flat approach.The following algorithm sketch shows how the hierarchicalapproach can be utilized to calculate all minimal diagnosis. Inthe algorithm a tree of sets of diagnoses with refinement ateach level is generated. For ease of presentation, we use a listdata structure (DiagsList) to hold the individual nodes (diagnoses)of the tree.Algorithm (sketch)DiagsList = [];D = diagnose(DD,E + ,E − ,Σ, ∅)/* Compute a set D of initial diagnoses on themost abstract level */Append all d ∈ D to DiagsList;index = begin of DiagsList;set E + = E + − {e + ∈ E + | e + consistent with DD}/* remove examples which are always consistent with DD */while not at end of DiagsListset d = diagnosis of current node;if d is expandablenewD = diagnose(DD,E + ,E − , Σ ,d);for all nd ∈ newDif nd is not already in list;append nd to DiagsList;endifend formove index to next element in DiagsList;end whileAfter the calculation of a diagnosis on the most abstract level,for each resulting diagnosis a node is generated and added tothe list of nodes to be refined. Remove all positive exampleswhich are definitely consistent with the domain description. Anode is expandable, if the diagnosis of that contains sentenceswhich are not leaf nodes of the hierarchical theory. A node isexpanded by calculating a new set of diagnoses in the contextof an abstract diagnosis according to the algorithm in Section4.1. For each of the refined diagnoses a new node is generatedif that diagnosis is not already somewhere in the tree (list).The algorithm ends, if no more node can be further expanded.The algorithm prunes out elements from the tree which werealready computed in another part of the tree.The following example illustrates the algorithm for our simplifiedexample. As a first step, an initial diagnosis on the toplevel is performed, yielding in the minimal diagnosis {PC}and {MB,CPU} for the abstract conflict sets {PC,CPU} and{MB,CPU}. Given the user wants to proceed to the next level,these diagnosis, which are at the top of the tree of diagnoses,are refined calling diagnose with the additional parameter ofthe more abstract diagnosis. The call to diagnose with (CPU,MB) results in the detailed diagnoses {MB 1 , CPU 1 }, {MB 2 ,CPU 1 }, and {PC}. Note, that the component PC was not refinedand in addition is redundant, because it is already in thetree of diagnoses (DiagList). The diagnose call with {PC}returns {PC1} and {MB, CPU}, where the latter is also redundant.At this stage, the tree of diagnoses cannot be refinedanymore, since we already reached the lowest level of detail.As a result, the lowest level diagnoses {PC 1 }, {MB 1 ,CPU 1 },and {MB 2 , CPU 2 } are returned.After the computation of all detailed diagnoses, the final tree(DiagList) of refined diagnoses is:diagnose(MB,CPU)(MB,CPU)(PC)(MB 1 , CPU 1 ) (MB 2 , CPU 1 ) (PC) (PC 1 )Not refinablediagnose(∅)diagnose(PC)(MB,CPU)Redundant(already in tree)Figure 2 Tree of diagnoses for example problem5 EXPERIMENTAL RESULTSIn order to test the applicability of our approaches, we implementeda prototype using the industrial strength softwarelibrary ILOG Configurator [14]. Using this package of C++libraries, a configuration problem is formulated in terms of aGenerative Constraint Satisfaction Problem (CSP) [8]. Thisenhancement of the basic CSP mechanism allows the numberof variables of the problem to be dynamically changed, i.e.,the number of employed components may not be known beforehand.The conceptual model of this library strongly correspondsto the notion of the component port model from Section3. Both the domain description (types, attributes, andports), the additional constraints, and the examples can bestated using calls to the library.In the context of that CSP, a conflict set is a set of constraintsfrom the knowledge base, which, if canceled, makes the configurationproblem satisfiable, i.e., a solution can be found.Using this library, the search for an arbitrary solution for aconfiguration problem can be done very efficient, especially incases when the problem is underconstrained which is notunusual for configuration problems. However, the employedlibrary does not offer adequate explanation mechanisms whichwould be helpful for the calculation of (minimal) conflict sets.We implemented the diagnostic algorithm both for the flatapproach from [7] and the extended hierarchical algorithmpresented in this paper. The computation time for the diagnostistask depends on several factors such as number ofconstraint types, cardinality of the diagnoses or the time to testone individual example for consistency. Diagnosis of thesimple example problem can be done nearly instantaneouslywith both algorithms; the identification of two triple faults in asetting with about twenty types of constraints and about hundredconstraint instances is done in a few seconds on a standardPentium-II PC running Windows NT with both algorithms.For these tests we employed our unoptimized prototypewhich does not calculate minimal conflict sets nor utilizesany special heuristics. However, for larger knowledgebases (containing about hundred types of constraints andcomponent types), the performance of the diagnostic taskusing the flat approach degrades strongly when calculatingdiagnoses of higher cardinality. In these cases, the usage of the27

hierarchical (interactive) approach with refinement of thediagnoses leverages this problem, if we assume that the givenconstraints are (uniformly) distributed among the componenttypes. When considering our simple example, the Floppycomponent will only be considered as one single element ofthe conflict sets and will never be expanded to a more detailedlevel. With this approach, even larger and more complexknowledge bases remain diagnosable within an acceptablecomputation time, because additional constraints within thecorrect parts of the knowledge base only influence the costs ofthe consistency checks but not those of the diagnostic algorithm.In addition, we conducted experiments with real-worldexamples from the domain of private telecommunicationsystems. The tests showed that the results from the diagnosticprocess are suitable for debugging and validation purposes.6 RELATED WORKModel based diagnosis techniques were initially developed forthe identification of faults in physical devices, e.g., electroniccircuits. Later, these techniques were adopted for diagnosisand debugging of software, e.g., logic programs [5] or relationaldatabase consistency constraints [12]. Currently, workis underway to employ MBD techniques to debug other typesof software with non-declarative semantics (e.g., hardwaredesigns specified in VHDL [10]). [11] use model based diagnosisto find solutions for overconstrained Constraint SatisfactionProblems, which can also be achieved using our approachthrough the assignment of weights of importance to theindividual constraints. The use of MBD techniques to solveoverconstrained CSP’s has also been proposed in [1].The usage of hierarchies for the diagnosis task has been discussedin various application areas of model based diagnosis[16]. Our approach mostly corresponds to what is calledstructural abstraction (vs. behavioral abstraction). One of theimportant problems is to have the information on the hierarchyavailable at each abstraction level (causing additional modelingeffort). For the case of debugging of constraint knowledgebases, however, the hierarchical abstraction has a good correspondenceto the configurable artifact, whereas in other domainsof (software) debugging, this abstraction may be morecomplicated to define. Furthermore, we found our logicalmodel of configuration and our configuration language to beexpressive enough to cover a wide range of configurationproblems. In addition, in [6] framework is defined, whereconfiguration knowledge bases of this type can be automaticallygenerated from high-level conceptual product models.7 CONCLUSIONSThe demand for AI-based product configuration technology issteadily increasing, due to the growing relevance of masscustomizedproduction and the increasing complexity of theresulting knowledge bases. For the validation and maintenancetasks, only limited support can be found in nowadays systems.For these tasks, we show, how techniques from model baseddiagnosis can be utilized in supporting the knowledge engineerin validating the knowledge base. Given positive andnegative examples (maybe from former configuration runs),the knowledge base is diagnosed and possible explanations forthe unexpected behavior are generated. These results can serveas a pointer for the knowledge engineer, which of the constraintsmay have to be revised to obtain a correct knowledgebase. For large and complex knowledge bases, the usage ofhierarchical structural abstraction which is given by the problemstructure can improve the efficiency of these diagnosticalgorithms. We have sketched a basic algorithm which allowsfor iterative (and interactive) refinement of diagnoses, wherefurther improvements, e.g., through reuse of conflict sets, arepart of our future work.The usage of an industrial strength configurator library alleviatesthe further integration of AI technology in standard softwareenvironments.8 REFERENCES[1] R.R. Bakker and F. Dikker and F. Tempelman and P.M. Wognum.Diagnosing and solving over-determined constraint satisfactionproblems. Proc: IJCAI’93, p. 276−281, Chambery,Morgan Kaufmann, 1993.[2] Virginia E. Barker and Dennis E. O’Connor. Expert systems forconfiguration at Digital: XCON and beyond. Comm. ACM, 32(3): 298-318, 1989[3] G. W. Bond. Top-down consistency based diagnosis. In ProceedingsDX’96 Workshop, Val Morin, Canada, 1996[4] D. Brady, K. Kerwin, D. Welch et al.: Customizing for themasses, Business Week, No. 3673, March 2000.[5] L. Console, G. Friedrich, and D.T. Dupré: Model-based diagnosismeets error diagnosis in logic programs. In Proc. IJCAI’93,Chambery, Morgan Kaufmann, 1993.[6] A. Felfernig, G. Friedrich, and D. Jannach:, UML as domainspecific language for the construction of knowledge based configurationsystems, in Proceedings: SEKE'99, 1999.[7] A. Felfernig, G.Friedrich, D. Jannach, and M. Stumptner, Consistencybased diagnosis of configuration knowledge-bases. InProceedings: ECAI’2000, Berlin, August, 2000.[8] G. Fleischanderl, G. Friedrich, A. Haselboeck, H. Schreiner andM. Stumptner, Configuring Large Systems Using GenerativeConstraint Satisfaction, IEEE Intelligent Systems, July/August,1998.[9] G. Friedrich, Theory Diagnosis: A Concise Characterization ofFaulty Systems, in: Proc. IJCAI'93, Chambery, France,1993.[10] G. Friedrich, M. Stumptner, and F. Wotawa: Model-BasedDiagnosis of Hardware Designs, in Artificial Intelligence, Vol.111, Num. 2, 1999.[11] E. Freuder, R. J. Wallace: Partial Constraint Satisfaction, ArtificialIntelligence (58), 1992.[12] M. Gertz, U. Lipeck. A Diagnostic Approach to RepairingConstraint Violations in Databases. In Proceedings DX’95 Workshop,Goslar, 1995.[13] R. Greiner, B.A. Smith, and R.W. Wilkerson: A correction to thealgorithm in Reiter’s theory of diagnosis. Artificial Intelligence,41(1), 1989.[14] D. Mailharro: A Classification and Constraint-based Frameworkfor Configuration, AI EDAM, Vol 12 (1998), Cambridge UniversityPress, 1998.[15] S. Mittal and F. Frayman, Towards a generic model of configurationtasks, in Proceedings: IJCAI'89, 1989.[16] I. Mozetic: Hierarchical Model Based Diagnosis, in: Harmscheret al.: Readings in Model Based Diagnosis, Morgan Kaufmann,1992.[17] R. Reiter: A theory of diagnosis from first principles. ArtificialIntelligence, 32(1), 1987.[18] M. Stumptner, An overview of knowledge-based configuration,AI Communications 10(2), pages 111-126, 1997.28

vxwjy|{ƒp‘r¢„)p‹’ ‚…€Py|pž’ {}†œy—v|{}Iu y|‚g’cŒgp‘r sAt‘u vxwjy|{ƒp‘r¢~ v|p‘I€}‚g„†—p‘€ƒŠ‹{}rItR¢u¸ 5qO‹:I¹=79[CJ›ORB0¹•5 · £©£¦¥ ! ¤¡"£¦©#$¡%£'&)( *¥ ¢¡¤£¦¥¨§©£¦¡¡+§©£¦©#!,.-0/214365879/2:-0?@/2:A5CB0D4EGF:`_acbedgfghjiAklflmonqplrRsAtluRvxwzy|{}plr#~Rv|pl €ƒ‚…„)†‡wjv|‚ˆwy|‰ v|{}Š‹{}rIt'wz~I~I€}{}Œ wjŽy|‰ ‚{}r‹y|‚@v|Œ@‰Iw‘rIt‘‚p‘6ªu rIŒ…y|{}p‘rAw‘€ewzv|Œx‰I{Ÿy|‚gŒ…y|uRv|‚g†g¢›µ uIrIŒ@y|{ƒp‘rAwz€¥wzv|Œx‰I{ŸŽy|{}plrKwzv|‚gw4p‘v’R‚gŒg€ƒwzvxwjy|{}Š“‚•”‹r pj–4€}‚ ’Rtl‚6v|‚g~ v|‚…†—‚gr˜yxwzy|{}plry|‰Awjye‚@š ~›‚@v|{}Žy|‚…Œ…y|u v|‚g†=¿}À ûzÁ›’ ‚@y|‚…v|„){}rI‚9ü¥ý þ‘ÿ¥Œ w‘rž›‚®v|‚gw‘€}{}g‚ ’ž˜ ‡wM~ v|p‹’ u Œ…y ¤‘{â‚l¢‚grIŒ…‚g†qwŒgp‘rI†œyxwzr‹y•{}rIŒ…v|‚gw‘†—‚9{}r)†—{}g‚Cw‘rI’žŒgpl„)~ €ƒ‚@š {Ÿy¡ Gpz>”‹r pj–4€}‚ ’Rtl‚†—~›‚…Œg{Ÿ Gy|‰ ‚®ªu rIŒ…y|{}plr †qwM~Rv|p‹’ u Œ…y6~ v|pjŠ‹{ƒ’ ‚g†{}rIŒg€}uA’R{}rItMŒgp‘rI†œy—vxwz{ƒr˜y|†Awz†—‚g†g¢£9p –q‚gŠ“‚…v ¤¥y|p‹’ wg 2¦†§ŒgplrRsAt‘u vxwzy|pzv|†)wzv|‚¨’R‚g†—{}tlrI‚g’#p‘vG†—pl€}Š˜Ž›‚@y0–®‚…‚grÄy|‰Ipl†—‚ªu rIŒ…y|{}plr †'w‘rI’ w„ˆw‘~ ~I{}rItÖv|pl„uIr Œ…y|{}plrI†cy|p{}rIt8€ƒp˜Œgw‘€˜Œgp‘r sAt‘u vxwjy|{ƒp‘r‡~Rv|pl €ƒ‚…„)†erIpzy¥~Rv|pzŠ‹{ƒ’ {}r tCwzr˜ K’ {}†œy—v|{}IuRy|‚ ’Œ…pl„)~›plr ‚gr˜y|†§y|‰ ‚)sArAwz€®~ v|p‹’RuIŒ…y‡Œ wzr¬›‚¨Iu {}€}yGp‘§¯¡ý ¡ üŒ wzry|‰ ‚ŒgplrRsAt‘u vxwzy|{}p‘rG~ v|p‘I€}‚g„©†—p‘€ƒŠ‹{}rItCªuIr Œ…y|{}plrIw‘€}{Ÿy0 ˜¢lnqplr †—‚ «˜uI‚gr˜y|€Ÿ Ky|‰I‚uIr Œ…y|{}plrI†9›‚G{}„)~I€}‚g„)‚gr˜y|‚ ’I´@¢P²p‘†œy|€} ˜¤2Œgu †œy|pl„)‚…v|†Mwzv|‚žr p‘y{}r˜y|‚…v—ŽŒ@‰Iw‘€}€}‚grIt‘‚g†Gp‘vžy|‰ ‚cŒgp‘rI†œy—v|u Œ…y|{}plrp‘CŒgplrRsAt‘u vxwzy|{}p‘r¬†œ R†œy|‚g„)†Gwzv|‚‚…†œy|‚ ’#{ƒr#y|‰ ‚c’R‚…yxw‘{}€}‚ ’~ v|p‹’RuIŒ…y§y|pl~›p‘€ƒp‘t‘ u y§vxwzy|‰I‚@vž†—~›‚gŒg{ŸÖ ¬wy|‰I‚c{ƒr˜y|‚gtzvxwzy|‚ ’¬†—uI~ ~›p‘v—ŷ p‘9ŒgplrRsAt‘u vxwzy|{}p‘r^”‹rIp –4€}‚ ’ t‘‚'Awz†—‚'’ ‚…Ž†—‚@yKp‘®uIrIŒ@y|{ƒp‘rI†My|‰ ‚ž~ v|p‹’RuIŒ…yK„‡uI†œyM~Rv|pjŠR{ƒ’R‚l¢>½®‰I‚)Œgp‘r sAt‘u vxwjy|p‘vŠ“‚g€}pl~ „)‚gr˜yKw‘rI’¦„ˆwz{ƒr˜y|‚grIw‘r Œg‚)w‘rI’y|‰ ‚ž{}r‹y|‚…t‘vxwzy|{}p‘r#p‘=„)‚…y|‰ p‹’ †‚…{}y|‰ ‚…v¨ŒgplrRsAt‘u v|‚g†ˆy|‰I‚'Œgpzv—v|‚g†—~›plrI’ {}rIt#~Rv|p‹’ u Œ…ÿ p‘vc{ƒrRªpzv|„)†ˆy|‰ ‚y|‰Awjy4‚grAwzI€}‚K’ {}†œy—v|{}IuRy|‚ ’cŒgp‘r sItlu vxwjy|{}plr¢~Rv|plI€}‚g„†—p‘€}ŠR{}r t ¢Œ…uI†œy|pl„)‚@v§w‘›pluRy§{ƒr Œgpl„)~Iwzy|{}I€}‚žv|‚ «˜u {}v|‚…„)‚gr˜y|†g¢ ­ r¦y|‰ ‚Gªp‘€ƒ€}p –4{}rIt­ r§y|‰ {}†~Aw‘~›‚@v¥–®‚=†—‰ pj–‰ p –#y|p9‚g„)~ €ƒp KwC†œyxw‘rA’ wzvx’§’ ‚g†—{}t‘rG€ƒw‘rRŽ–q‚¢’R{ƒ†—Œ…uI†—†)w*†—{}„){ƒ€ƒwjv)†—Œg‚grIwzv|{}p ¤•{}r–4‰ {}Œ@‰¬ŒgplrRsAt‘u vxwzy|pzv|†)w‘Œ@ŷ w‘†y|{}plrpz4ŒgplrRsAtluRvxwzy|{}plr#”‹r pj–4€}‚ ’Rtl‚ˆAwz†—‚g†¨¯±Œgpl„)~›p‘rI‚gr˜yK†œy—v|uIŒ@y|u v|‚½®‰I‚$’ ‚gŠ“‚…€ƒp‘~I„)‚gr˜ÿ ~ v|p˜Œg‚g†—† p‘vSŒgp‘r sAt‘u vxwjy|{ƒp‘r †œ R†œy|‚g„)† {}†tluIw‘tl‚ˆ¯±°CrI{ŸsA‚ ’²p‹’ ‚g€}{}rIẗ ³>w‘rIt‘uAwztl‚Žq°M²¢³¥´qªpzvCy|‰ ‚Œgplr †œy—v|uIŒ…ŽŒ…uI†œy|pl„)‚@v|†4w‘rA’¨†—uI~ ~I€}{}‚…v|†g¢v|‚g†—uI€Ÿy|{}rIt8„)p‹’ ‚…€ƒ†e{ƒr˜y|pCw‘r§‚…šR‚gŒguRyxw‘I€}‚•€ƒp‘tl{}Œqv|‚g~Rv|‚g†—‚gr˜yxwzy|{}p‘r§–4‰ {ƒŒx‰Œ…plr sItluRvxwzy|{}plr”‹rIp –4€}‚ ’ t‘‚cIw‘†—‚¨Œgplr †—{}†œy|{ƒr t¦pzCuIr Œ…y|{}plrAwz€=wzv|Œx‰I{ŸŽw‘rI’'uIr Œ…y|{}plrAwz€6wzv|Œx‰I{Ÿy|‚gŒ…y|uRv|‚j´9wzrA’*w‘uRy|pl„ˆwzy|{}Œ wz€}€} 'y—vxwzrI†—€ƒwzy|‚‡y|‰I‚†—”l‚…y|Œ@‰ ‚ ’¢{}r¼µ¥{}t‘u v|‚cÀ‘¢2½®‰I‚‡†œyxwzv—y|{}rIẗ ~›pl{}r˜y{}†9y|‰I‚‡’ ‚…†—{ƒt‘r¦pz•y|‰ ‚y|{}plrI†g¢Rµ uIrIŒ@y|{ƒp‘rAwz€›wzv|Œx‰I{Ÿy|‚gŒ…y|uRv|‚g†=wjv|‚C†—‰Iwzv|‚ ’¨w‘„)p‘rItKŒgp˜pl~›‚@vxwzy|{}rItpzvx’ ‚…v‡y|p*†—{ƒ„)~ €}{}Ö ¼y|‰ ‚¨Œ…plrI†œy—v|u Œ…y|{}plrp‘9w'Œgplr †œy—vxw‘{}r˜y—Ž»Aw‘†—‚g’¬’R‚…ŽŒ w‘ržu v—y|‰ ‚…vq›‚8‚…šR~I€}p‘{}y|‚g’Gªp‘vqŒ w‘€}Œgu €ƒwzy|{}rIt‡’ {}†œy—v|{}IuRy|‚ ’GŒgp‘r sAt‘u vxwjŽy|‚…Œ…y|u v|‚g†¿}À û‘ÁKwzrA’Nw#Œgp‘v—v|‚…†—~›plrA’R{}rIt¬Œgpl„)~›p‘rI‚gr˜yc†œy—v|uIŒ…y|uRv|‚l¢ ­ r«˜uI{Ÿv|‚g„)‚gr˜y|†=›‚…y¡–®‚g‚gr¢y|‰ pl†—‚†œ R†œy|‚g„)†g¢ACr¢‚…š wz„)~I€}‚9ªpzvMŒgp‘r sItlu v—Ž²p‹’R‚g€}{}rIt‡³ew‘r tluIw‘tl‚‡¿ƒÀ ËzÁ䘖4‰I{}Œx‰¨{}†=wK†œyxw‘rI’Iwjvx’¨’R‚g†—{}tlr¨€ƒw‘rIt‘uAwztl‚ŒgplrRsAt‘u vxwzy|{}p‘r†œ R†œy|‚g„)†®†—‚…v|Š‹{}rItGw‘†=Iw‘†—{}†=ªp‘v=y|‰ ‚M‚…šRŒx‰Aw‘r tl‚Cp‘¥v|‚…Ž†—Œ@v|{ƒ~Ry|{}plrpzey|‰ ‚’ p‘„ˆw‘{}rc”‹r pj–4€}‚ ’Rtl‚9–q‚M‚g„)~ €ƒp )°M²¢³Ž6°CrI{ŸsA‚ ’{}rIt8Œ wzv|††—‰ pj–4†¥y|‰ ‚•–4‰ pl€}‚®~ v|p˜Œ…‚g†—†¥v|p‘„¨y|‰I‚•’ ‚g†—{}t‘rGp‘ y|‰I‚ŒgplrRsAtzŽ–4{ƒ’R‚g€Ÿ w‘~I~ €}{ƒ‚g’¦{}r¦{}rI’ uI†œy—v|{ƒwz€†—pzy¡–=wzv|‚ˆ’R‚gŠ“‚g€}p‘~I„)‚gr˜yC~ v|p˜Œg‚g†—†—‚…†g¢µ p‘v¢†—‰Iwzv|{}rItŒgp‘r sItlu vxwjy|{}plrN”‹rIp –4€}‚ ’ t‘‚¼›‚…y¡–®‚g‚grN’R{ŸÇP‚…v|‚gr˜y†œ R†œŽ‚¼‚…šRŒx‰AwzrItl‚¼p‘žuIrIŒ@y|{ƒp‘rAwz€Gwjv|Œ@‰ {}y|‚…Œ…y|u v|‚g†g¤{±¢‚l¢•{ŸKw¦Œgp‘r sItlu vxwjy|p‘vˆ–=wzr˜y|†žy|p¼p‘vx’R‚…vˆ~ v|p‹’RuIŒ…y|†žÖv|pl„ wzrIp‘y|‰ ‚…vy|‚…„)†–®‚#~Rv|pl~›pl†—‚y|‰Œ…plr sItluRvxwzy|p‘v‡{ŸyG„‡uI†œyK{}r˜y|‚gt‘vxwjy|‚)y|‰I‚)ªu rIŒ…y|{}plrIw‘€qwzv|Œx‰I{Ÿy|‚gŒ…y|uRv|‚¨pzw)†—uIŒgŒg‚…†—†œªuI€ ­ w‘~I~ €}{ƒŒgwzy|{}plr¼wzv|‚ ẅ w‘rI’'y|p‹’ wg ¢ªpzv|„y|‰I‚pluIrI’IwjŽ½®‰ ‚v|‚…†—uI€Ÿy|{}rIt8Œgplr Œg‚g~ y|uIw‘€“Œ…plr sItluRvxwzy|{}plr§„)p‹’ ‚g€l{ƒ†¥w‘u y|p‘„ˆwzy|{}Œ wz€ƒ€Ÿº rIp –4€}‚ ’ t‘‚…Ž»Awz†—‚ ’§Œ…plr sItluRvxwzy|{}plr‡†œ †œy|‚…„)†e‰Aw Š“‚qw8€}p‘rIt9‰ {}†œy|p‘v— §w‘†y|‰ ‚)’ ‚…†—{}v|‚g’¦~ v|p‹’RuIŒ…yK{}r˜y|p{Ÿy|†K€}p˜Œ w‘€•”‹rIp –4€}‚ ’ t‘‚)Aw‘†—‚¯±~I‰Awz†—‚Àj´@¢y|{}plrp‘vCw‡y|‰ v|{}Š‹{}rIt‡{ƒrI’ u †œy—v— *¯±‚l¢t ¢Iy|‚…€ƒ‚…Œgpl„)„‡uIrI{}Œ wjy|{}plr†œ R†œy|‚g„)†g¤y—vxwzrI†—€ƒwzy|‚g’§{}r˜y|p8w4v|‚g~Rv|‚g†—‚gr˜yxwzy|{}p‘r‡‚…šR‚gŒ…u yxw‘ €}‚•˜ My|‰ ‚•Œgpzv—v|‚g†—~›plrI’RŽw‘uRy|pl„)p‘y|{}Š“‚§{}rA’RuI†œy—v— ˜¤AŒ…pl„)~IuRy|‚…vC†œ †œy|‚…„)†9‚…y|Œl¢´@¢2½®‰ ‚g†—‚G†œ R†œy|‚g„)†{}r tŒgp‘r sAt‘u vxwjy|{ƒp‘r¼†œ R†œy|‚g„ ¢>Ì‹{ƒr Œg‚žp‘u vKtlplw‘€{}†My|p†—uI~ ~›p‘v—yKŒgp˜p‘~ Ž‰Aw Š“‚€}{}”“‚…–4{}†—‚G~Rv|pltzv|‚g†—†—‚ ’¢v|p‘„¾y|‰ ‚g{Ÿv9†—u ŒgŒg‚g†—†œuI€ev|u €ƒ‚@Ž¡Iw‘†—‚ ’¢pzv|{ŸŽ‚@vxwzy|{}Š“‚¨ŒgplrRsAtluRvxwzy|{}plr2¤¥y|‰I‚ˆy—vxw‘r †—€ƒwzy|{}plr¬~ v|p˜Œg‚…†—†ž„Gu †œy‡t‘‚grI‚@vxwzy|‚tl{}rI†M¿}ÀgÁPy|p§y|‰I‚Mu †—‚Mp‘e‰I{}tl‰ ‚…v4€}‚gŠ“‚g€Pv|‚g~ v|‚…†—‚gr˜yxwzy|{}plr †=†—uIŒx‰¢w‘†=Š‘wzv—Žwžv|‚g~Rv|‚g†—‚gr˜yxwzy|{}p‘r¼wz~I~I€}{}Œ wzI€}‚G˜ 'ẅ ’ {}†œy—v|{}IuRy|‚ ’'~ v|p‘I€}‚g„¾†—pl€}Š‹{ƒr t{}pluI†ˆªpzv|„)†cpzKŒgplr †œy—vxw‘{}r˜y†|wjy|{}†œ±w‘Œ@y|{ƒp‘rS¿}Àg‘Áä=’ ‚…†—Œ…v|{}~ y|{}plrÄ€}plt‘{}Œg†wz€}tlp‘v|{Ÿy|‰ „ ¯±~I‰Awz†—‚Å‘´@¢Iµ p‘v4tlu {ƒ’ {}rIt§y|‰I‚9~Rv|pl €ƒ‚…„$†—pl€}Š‹{}rItG~Rv|p˜Œg‚g†—†¿}ÀjÅzÁä‘p‘v6ªu rIŒ…y|{}plrIw‘€‹v|‚ w‘†—p‘rI{}rItž¿}ÀgÆ‘Áä“’RuI‚qy|p8y|‰I‚®†—{}tlr {ŸsAŒ wzr‹y•w‘’ Š‘w‘r Žpzž’R{}†œy—v|{ƒ u y|‚ ’ÄŒgp‘r sItlu vxwjy|{}plrN–®‚‚g„)~I€}p þ£¢¥¤§¦©ẍý ¡ ¦ ¡£ ¢xþ¨£yxw‘t‘‚g†žp‘ÇP‚@v|‚ ’2È„)pzv|‚ˆŒgplr Œg{}†—‚¨v|‚g~Rv|‚g†—‚gr˜yxwzy|{}p‘r>¤6‰I{}t‘‰I‚…v‡„ˆw‘{}r˜yxw‘{}r Žÿœþ¨§¦¨~ v|p‘~›pl†—‚ ’¨˜ ¿Å˜ÀgÁäR–4‰ {}Œ@‰¢pzÇP‚…v|†®y|‰I‚9Aw‘†—{}†=ªpzv8›pluIrI’ ‚ ’w‘ {ƒ€}{Ÿy0 ˜¤lw‘rI’‡„)pzv|‚®ÉA‚…šR{}I€}‚qv|‚ wz†—plr {ƒr t ¢‹µ u v—y|‰I‚@v|„)p‘v|‚l¤ y|‰ ‚={ƒr Œ…v|‚ wz†œŽ€}‚ wjv|rI{}rIẗ †œy—vxwzy|‚…tl{}‚g†M†—u ~I~›p‘v—y|{}r ẗ y|‰ ‚Kv|‚g’ uIŒ@y|{ƒp‘r*p‘•†—‚ wzv|Œx‰¦‚@ÇPp‘v—y|†{}rIt'’R‚g„ˆw‘rI’*p‘vGw‘~I~ €}{ƒŒgwzy|{}plr †‡~Rv|pzŠ‹{ƒ’ {}r t†—pl€}uRy|{ƒp‘rI†KªpzvGŒgp‘r sItlu Ž¯±~ ‰Awz†—‚û“´@¢vxwzy|{}plr*yxw‘†—”‹†M{}†M›p˜p‘†œy|‚ ’*‹ y|‰I‚§„ˆw‘†—†MŒgu †œy|pl„){} wjy|{ƒp‘r*~Awzvxw‘’ {}tl„½®‰I‚‡~Awz~›‚…vK{}†p‘v|t“wzrI{}g‚ ’¼w‘†Mªp‘€}€ƒp –4†g¢¥µ¥{}v|†œy ¤2–®‚G v|{}‚…ÉI *†—”l‚…y|Œ@‰w‘rI’c‚…Ž»Iu †—{}rI‚g†—†8w‘~ ~I€}{}Œ wzy|{}p‘rI†g¢y|‰ ‚ž’R‚g†—{}tlrpz4wcŒgp‘r sItlu vxwjy|{}plr„)p‹’R‚g€uI†—{}rIt°²¢³N¯»ÌR‚gŒ…y|{}p‘r#Ål´@¢Ê †—~›‚gŒg{ƒwz€ƒ€Ÿ cy|‰I‚{}r˜y|‚gt‘vxwjy|{ƒp‘r'p‘6Œgp‘r sItlu vxwjy|p‘v|†8{}r¢p‘vx’R‚…vCy|pG†—uI~ Ž­ r*ÌR‚…Œ…y|{}plr'ûG–q‚‡t‘{ƒŠl‚KwGªp‘v|„ˆwz€’ ‚@sArI{Ÿy|{}plrp‘w)’ {}†œy—v|{}IuRy|‚ ’Œgp‘r Ž~›p‘v—yŒ…p˜pl~›‚…vxwjy|{ƒŠl‚žŒgplrRsAt‘u vxwzy|{}p‘r¼†—uIŒx‰¦w‘††—uI~ ~I€Ÿ 'Œx‰Awz{ƒr{}r˜y|‚gt‘vxwjŽsItluRvxwzy|{}plr'yxw‘†—”cAwz†—‚ ’'plr¢y|‰I‚KŒgp‘„)~›plr ‚gr˜y9~›pzv—y9„)p‹’R‚g€•¿}À ûlÁ¥w‘rI’y|{}plrpzŒgu †œy|pl„){} w‘ €}‚~ v|p‹’ u Œ…y|†={}†4w‘rcpl~›‚grv|‚…†—‚ wzv|Œx‰{}†—†—uI‚‘¢Pnqu v—Ž†—‰ p –‰Ip –y|pCy—vxwzrI†—€ƒwzy|‚®wCŒgp‘r sAt‘u vxwjy|{ƒp‘r‡„)p‹’R‚g€‹’ ‚…†—{ƒt‘rI‚ ’§{}r‡°M²¢³v|‚gr˜yqŒ…plr sItluRvxwzy|p‘v=w‘~I~Rv|p“wzŒ@‰ ‚g†C¿ËzÁPwjv|‚9’R‚g†—{}tlr ‚ ’žªp‘v®†—pl€}Š‹{ƒr t‡€}p˜Œ wz€{}r˜y|pCy|‰ {}†eªpzv|„ˆw‘€}{}†—„ ¢ ­ r‡pzvx’ ‚…vy|pC†—‰Ip –#y|‰I‚=wz~I~ €ƒ{}Œ wzI{}€}{Ÿy0 §p‘Pwz†œ Rr ŽŒgplrRsAt‘u vxwzy|{}p‘r#~ v|pl €}‚g„)†g¤¥ u yKy|‰I‚…v|‚ˆ{}†§†œy|{ƒ€}€®r p'†—uI~ ~›p‘v—yKªpzvžŒgpzŽŒx‰ v|p‘rIp‘uI†MIw‘Œx”‹y—vxwzŒ@”‹{}rItˆªpzv§’ {}†œy—v|{}IuRy|‚ ’Œ…plr sItluRvxwzy|{}plr¦~ v|pl €}‚g„w‘rI’¨~Rv|{ƒŠ‘w‘Œ@ )Œgplr Œg‚…v|r †4w‘†®–®‚…€ƒ€2wz†®y|‰I‚9{}„)~›p‘†—†—{ƒ {}€ƒ{Ÿy¡ ¨y|p§‚…šRŒx‰Aw‘r tl‚wc’ {}†œy—v|{}IuRy|‚ ’n=ÌÄv|‚g~ v|‚g†—‚…r‹yxwjy|{}plr¦–4‰ {}Œ@‰¦Œ w‘r›‚ž‚…šR~I€}p‘{}y|‚g’˜pl~›‚…vxwjy|{}Š“‚‡†—p‘€}ŠR{}r tcpz®’R{ƒ†œy—v|{} u y|‚ ’¢Œgp‘r sItlu vxwjy|{}plr*yxw‘†—”‹†g¢2ÌR‚…Œgu v|{Ÿy0†—p‘€}ŠR{}r tc–®‚§y—vxw‘r †—€Öwjy|‚Gy|‰I‚‡Œgpl„)~›p‘rI‚gr˜y9~›p‘v—yMv|‚g~Rv|‚g†—‚gr˜yxwzy|{}p‘r¼{}r˜y|pŒgplr †œy—vxw‘{}r˜y|†qv|‚g~Rv|‚g†—‚gr˜y|‚ ’ž{}r¨’ {ŸÇP‚…v|‚gr˜yv|‚g~ v|‚g†—‚…r‹yxwjy|{}plrˆªp‘v|„ˆwz€}{ƒ†—„)†wz†œ RrIŒx‰ v|plr plu †eAwzŒ@”˜y—vxwzŒ@”‹{}rItR¢ ­ r§Ì‹‚gŒ…y|{}plr=–®‚q†—‰ p –#‰Ip –¼y|p8†—‰Awjv|‚„ˆw‘”“‚K{Ÿy{}„)~›pl†—†—{} €ƒ‚§y|pˆŒg‚gr˜y—vxw‘€}{}g‚ž~Rv|plI€}‚g„¾†—pl€}Š‹{}rItc{ƒr*p‘rI‚GŒ…plr ŽuIr Œ…y|{}plrAwz€Mwjv|Œ@‰ {}y|‚…Œ…y|u v|‚g†c›‚…y0–q‚g‚grÄŒgp‘r sItlu vxwjy|{}plrĆœ R†œy|‚g„)†¨w‘rI’sAt‘u vxwzy|pzv ¢‰ p –^y|pKp‘v|tlw‘rI{}g‚Cy|‰I‚8€ƒp˜Œgw‘€›Œgp‘r sAt‘u vxwjy|{ƒp‘rc”‹r pj–4€}‚ ’Rtl‚8{}rcpzvx’ ‚…v•y|p­ rcpzvx’ ‚…v=y|pG„)‚g‚…y®y|‰ ‚g†—‚MŒx‰Aw‘€}€}‚gr tl‚g†g¤R–®‚~Rv|pl~›pl†—‚KwKvxwz„)‚…–®pzv|”wz†—†—u v|‚)y|p¢›‚)‚…šR‚gŒ…u yxw‘ €}‚)‹ ¦wz†œ r Œ@‰Rv|plr pluI†KIw‘Œx”‹y—vxwzŒ@”‹{}rItR¢¥µ u v—ŽªpzvM’R‚g†—{}tlrI{}r tˆw‘rA’¨{}r‹y|‚…t‘vxwzy|{}r t)ŒgplrRsAtluRvxwzy|{}plr'†œ R†œy|‚g„)†=Iw‘†—‚ ’cplry|‰ ‚…v|„)p‘v|‚)–q‚tl{}Š“‚cw‘r‚…š wz„)~I€}‚¨p‘vˆw*’R{ƒ†œy—v|{} u y|‚ ’#Œ wjv)ŒgplrRsAt‘u Žvxwjy|{}plr–4‰I{}Œx‰{ƒ†Kv|‚ wz€ƒ{}g‚g’¬˜ y|‰ v|‚g‚ˆŒgp‘r sAt‘u vxwjy|{ƒp‘r#†œ R†œy|‚g„)†c¯±Œgwzvß“ÓlÞzÑ¡ÒŸÜ Ï“Ð0ÒŸÏ‘ÔÜ ×»ÝKÛ…Ñ0ÒŸÞ‹å8è•ÏlÒéjâx×»Ð0ÒÑ0ê…Ñ¡Ð0СѡסÛgÐ0Ð0âë ì…çÃëjí‘å4à•çÃî ï ð ïñ®ò}Ûgã â|Ïl焈wzr‹u ±wzŒ…y|u v|‚@v ¤9‚g€}‚gŒ@y—v|{ƒŒ.‚ «˜uI{}~I„)‚…r‹y*†—u ~I~ €ƒ{}‚…v ¤Mw‘rI’ „)p‘y|p‘v—Ž»u rI{ŸyÍeαÏlСѡÒÑ0ÓlÑPÔÖÕ“×Aئҟ׻ѡÐ0ٜړۅÔÖÑ¡Ð0ÒŸÏlÔÖÜ ×»ÝKÛ…Ñ0ÒŸÞ4Ó“Ï“ß8àqÏjáâ|Ï“ß“ÓlÏ“ã Ð0лälлÑ0â|Ýâ å æ2סÜgçÔÖÓ“×ÃÑ@åPà•Ó“СѡסÒ}Ûlå2â|ÝKÛgÒŸòªó2ôxÔÖâ|òÔâ|׻ϓҟã“åÔÖסҟâ|ߓ׻ҟٜÚIåõ¡ÛgϓϘÛgÙœÚ åö@ÛgÏlÞ âxל÷gøqÒùAúÓ“ÏlÒ熗u ~I~ €ƒ{}‚…v@´@¢PÌR‚gŒ…y|{}p‘rI†ˆw‘rI’ ¨Œ…plr˜yxw‘{}r'v|‚g€ƒwzy|‚ ’¢–qp‘v|”'wzrA’'tl‚gr ‚…vxw‘€ÞzòŸÓIúÛgÙ úÛ…Ñ@úŒ…plrIŒ…€ƒu †—{}plrI†g¢ÅzÂ

!!Ü Ïlù˜ã Ól×0Û…Ñ¡ÒŸÜ ÏžÐ¡ä‘Сѡâ|ݨߓâ—éjâ|òŸÜ43“Ýâ|ÏjÑ53“×»ÜzÙxâ|СÐ$&%(')+*-,/.021LÄ/>\RB0D•59Bœ58D©JP¹q587MD•[C:I3¥ORB¡¹q5Z45C¹:9¬-¡/>7CD•/7©¨¹•5j7MD•[C: 3¥ORB0¹•5«ª§3\RZ¦r.y|‰ {ƒ†ˆ†—‚gŒ@y|{ƒp‘r

@@$ %i')+*-,T­q0¯® Ó“Ï“Ù—Ñ0ÒŸÜ Ï“Ûgò›ÛgסÙ0Ú“ÒÑ0â|ٗѡӓסâ|Ð4Ûgϓ߇Ù|Ü Ý3RÜ ÏlâxÏjÑ•ÝKÛ`33“ÒŸÏ“ãCÜgÔW¡£Y ´=wzrA’w‘’I’R{}y|{}p‘rAw‘€>Œgplr †œy—vxw‘{}r˜y|†Cp‘r¢€}‚gt“wz€eŒgp‘r sItlu vxwjy|{}plrI†g¢A½®‰I‚ÀZÁ ¦Kçw‘rA’Ħ'{}†8y|‰ ‚Mr‹uI„‡›‚…v=p‘¥Œgp˜pl~›‚…vxwjy|{}rIt)Œgp‘r sAt‘u vxwjy|p‘v|†x´@¢y|‚grIŒ…‚g†Ç^È¢ÉIÊ ¸ µq± ¸ÌË&Í/Î µ±jÏ´ºÌºK·µq± ¸ÌË ÊjÊ µÐ ¢ ­ r¬y|‰ ‚g†—‚¢†—‚…y|†@¸ µd¼2½ÑÈ¢ÉIÊ ¸ µ¾—¤•–4‰ ‚…v|‚ÒÈ¢É©Ê ¸ µ¾Kv|‚g~Rv|‚g†—‚gr˜y|†ˆ†—‚…y|†ˆp‘È¢É©Ê ¦©¨Çx¨-±ªÿ(Ð ¢Mÿˆ{}†c{}r Œg€}uA’ ‚g’^{}r ¸ÌË ÊjÊ´µQ>rÏ´ºÌºK´µR>rÏSB|¨ ¡£Y UÒ¢¨ ¡ ¦¢¥¢|ÿxXQ¦Iÿ ¸ÌË&ͲÎ{}†e†—‚gr˜y|‚gr Œg‚6{ƒ†2ªu €}sI€}€ƒ‚g’K{Ÿ‹–®‚•w‘€}€}p –#{}r~³´³£Ï´ºÌºK·µU>2ÏSBED#FG!H{}†'wŒgp‘„)~I€}‚…y|‚*y|‰I‚gpzv— ÛgÙ|Ù|Ü Ý3“òŸÒŸÐ0Ú“â|ß {jäCÛgß“ß“ÒÑ¡ÒŸÜ Ï˜Ûgò˜òŸÜ ã ÒŸÙxÛgò˜Ð0â|ÏjÑ0â|Ï“Ù|â|ÐeáÚ“ÒŸÙœÚCÙ@ÛgÏ{‹â0..1lights-functionelectric-equipment1..1battery-functionðQï4çöôëlÜ»í¥ðQä^à ã ê4ë»ÙÝxéá»ï-à ïâiõÞGßlÚ»Ülà à ï»÷Ké£÷Këã Ù^Ülñóòbatterylarge-battery-functionÙÝxô?Ülà Ü»á§Ùvâ(ã á§äiÜ»å4æã Û-ç:Üè»ÙõÞGßQà ã ê4ë»ÙÝäÛQïâ ÙoéZì¥ílÙ^Ù^Ü¥â¥ÚläÛQïâ ÙoéÛQïâã ê4ë»ÙÝä(î^æ-èlá§Ùã ï`èläÛQïâ Ùoé ì¥ílÙ^Ù^Ü¥â¥Úlä(î^æQè¥á§Ùã ï4è»äÛQïâ Ùñøqòàܧá§Ùvâ(ã á§äiÜ»åóæ¥ã Û-ç:Üè»Ùoéà ã ề ëlÙÝäÛQïâ ÙõÞGߥܥà Ü»á§Ùâiã áxä?ܧåóæã ÛQç:ÜèlÙ?äÛQïâ ÙñðQï4çöô?Ü¥àÙÝxôà ã ề ëlÙ^ÝvõÞGßÜlà Ü»á§Ùvâ(ã á§äiÜ»å4æã Û-ç:Üè»Ù^äÛQïâ Ùñ4òÛQïâÙÝxôìlílÙ^ÙÜlâ¥ÚõÞGߥܥà Ü»á§Ùâiã áxä?ܧåóæã ÛQç:ÜèlÙ?äÛQïâ Ùñ4òÛQïâfront-fog-lightsmedium-battery-functionÛQïâ ÙÝxôà ã ề ëlÙ^Ýä(î^æ-è¥áxÙã ï`èõÞGߥܥà Ü»á§Ùâiã á§äiÜ»å4æã ÛQçbÜ¥èlÙ^äÛQïâ Ùñ4òÙÝxôìlílÙ^ÙÜlâ¥Úlä(î^æ-èlá§Ùã ï`èõÞGߥܥà Ü»áxÙvâ(ã á§äiÜ»åóæ¥ã Û-ç:ÜèlÙ?äÛQïâ¥ÙñóòZò ò òÛQïâ(jý‹ÿ¢ s ¦+¨…ÿ ¡ ¦ú¥Xlk lXQ¢h}þ£X-§|þ‘ÿ±ÿxXQ¤ ¯Ãµ¥{}tluRv|‚½®‰I‚cv|‚g€ƒwzy|{}plrùhlarge-batterymedium-battery‘´®{ƒ†=y—vxwzrI†—€ƒwzy|‚ ’w‘†=ªp‘€ƒ€}p –4†¥û˜Èý¡¥`é Ü¥à Ü»á§Ùâiã á§äiÜ»å4æã ÛQçbÜ¥èlÙ^äÛQïâ ÙoéZü ý¡ -éì¥ílÙ^Ù^Ü¥â ÚläÛQïâ Ùõ§òá»ï`è-èVôü¡§Y URþ‘ÿv`hiX¢þ ÿ ¡§Y þ‘ÿv¨{}r.µ¥{}t‘u v|‚cû*{}†½®‰I‚ˆv|‚g€ƒwzy|{}p‘r§¦¨¦xýóUN¦+¨â|òŸâxٗѡסҟÙ4⥤zÓ“Ò¥3“Ýâ|ÏzÑСÓ33“òŸÒŸâ|×y—vxwzrI†—€ƒwzy|‚g’¢w‘†=ªp‘€}€ƒp –4†gÈw)†—‚…y9pz•uIr Œ…y|{}plrAwz€wzv|Œx‰I{Ÿy|‚gŒ@y|u v|‚g†8–4‰I{}Œ@‰'†—~›‚…Œg{Ÿ ¢y|‰ ‚KuIr Œ…y|{}plrAwz€Œgpl„)~›p‘†—{Ÿy|{ƒp‘r)p‘2wjv—y|{}ªw‘Œ…y|†•w‘rI’GŒgp‘rI†œy—vxw‘{}r˜y|†plrGy|‰ ‚g{Ÿv•Œ…pl„)~›pl†—{Ÿy|{}plr2¤{±¢‚‘¢Aw§†—‚…y4p‘erI‚gŒg‚…†—†|wzv— w‘rA’ˆpl~Ry|{}plrAwz€2uIr Œ…y|{}plrI†g¤ wzrA’cŒ…plrI†œy—vxwz{}r‹y|†plr'y|‰I‚…{}v9Œgpl„)~›p‘†—{Ÿy|{ƒp‘r#¿ÂzÁ»¤e¿ƒÀgû‘Áâ2½®‰I‚§†—‚…yMpz•uIr Œ…y|{}plrI†C{}†CªuRv—y|‰I‚…v’ ‚gr p‘y|‚ ’¬w‘†|s ¦+¨…ÿ ¡ ¦¢x¢qnqp‘„)~›plrI‚…r‹y‡y0 R~›‚g†)wz†ž–®‚g€}€8w‘†žuIr Œ…y|{}plry0 R~›‚g†§wzv|‚¨’R‚g†—Œ…v|{}›‚ ’¼y|‰ v|p‘uIt‘‰#w†—‚…y‡p‘4~Rv|pl~›‚…v—y|{}‚g†c¯|þ‘ÿ±ÿQ ÿxXQ¢g´@¤w‘rI’ˆŒ…plrIr ‚gŒ…y|{}plrc~›pl{}r˜y|†M¯U ¡ xÿ¢ ´•v|‚…~ v|‚g†—‚gr˜y|{}rIt§€}plt‘{ƒŒgw‘€2p‘v=~ ‰‹ R†—{}Œ wz€wz„)~I€}‚8p‘v8w§ŒgplrRsAtluRvxwzy|{}plr¨v|‚g†—uI€Ÿy=pzey|‰ ‚9‚g€}‚gŒ…y—v|{}ŒM‚g«‹u {}~ Ž„)‚…r‹y®†—uI~I~ €}{ƒ‚@v4{ƒ†4y|‰I‚Cªpl€}€}p –4{}rIt ÈCrˆ‚…šÜ»á§Ùvâ(ã á§äiÜ»å4æã Û-ç:Üè»Ù^äþé£Ü¥à Ü»á§Ùâiã á§äiÜ»å4æã ÛQçbÜ¥èlÙõ§ò4Ù(Ú-ÛQÜôà ã ề ëlÙ^ÝäþQéà ã ề ëlÙÝvõ§òÙ(Ú-ÛQÜô?Ülà‰Aw Š“‚wzr'w‘†—†—{}t‘rI‚ ’¢’Rpl„ˆwz{ƒr¦¯ W¡£Y ´@¢Œgplr rI‚gŒ@y|{ƒp‘rI†8y|p¨pzy|‰I‚…v9Œgpl„)~›p‘rI‚gr˜y|†g¢+°qp‘y|‰y±=þ‘ÿ±ÿv ÿxXQ¢žwzrA’²U ¡ xÿ¢Ù(Ú-ÛQÜôëlÜ»í¥ðQä^à ã ề ëlÙÝäþéë¥Ü»í¥ðQä^à ã ề ëlÙ^Ývõ§ò§Ù(Ú-ÛQÜôìlílÙ^ÙÜlâ¥Úläþéç:Ü»ð`ã æQç:äìlí¥Ù?ÙÜ¥â Úõ§ò½®‰ ‚§’ pl„ˆwz{}r'’ ‚g†—Œ@v|{ƒ~Ry|{}plr¯x³´³ž´=p‘w)Œgp‘r sAt‘u vxwjy|{ƒp‘r¢yxw‘†—”¢Œ…plr Žî^æQè¥áôìlílÙ^ÙÜlâ¥Úlä(î^æ-èlá§Ùã ï`èläþéç:Ü»ð`ã æQç:äìlí¥Ù?ÙÜ¥â Úlä(î^æ-èlá§Ùã ï`èõ§òá§ï4èQè-ôë¥Ü§íðä^à ã ê4ë»ÙÝäþQéà ã ề ëlÙ^ÝäÛQïâ Ùoéà ã ề ëlÙ^äþéë¥Ü»í¥ðQä^à ã ề ëlÙ^ÝäÛQïâ Ùõ§òá§ï4èQè-ôà ã ề ëlÙÝäþéÜ¥à Ü»á§Ùâiã á§äiÜ»å4æã ÛQçbÜ¥èlÙ^äÛQïâ ÙoéÜ¥à Ü»áxÙvâ(ã á§äiÜ»åóæ¥ã Û-ç:ÜèlÙ?äþQéà ã ề ëlÙ^ÝäÛQïâ Ùõ§òá§ï4èQè-ôì¥ílÙ?ÙÜ¥â ÚläþQé`Ü¥à Ü»á§Ùâiã áxä?ܧåóæã ÛQç:ÜèlÙ?äÛQïâ ÙoéóÜ¥à Ü»á§Ùâiã á§äiÜ»å4æã ÛQçbÜ¥èlÙ^äþéìlí¥Ù?ÙÜ¥â ÚläÛQïâ¥Ùõ§òyxw‘{}rI†.y|‰I{}† µ·µJ> È¢ÉIÊ ¸ µK> ¸ÌË&Í/Î µJ> ¸ÌË Ê·Ê´µJ>£Ï´ºÌºK·µ@ÏCBED#FG!H^¢u¨ ¡ ¦¢^¢xÿxXQ¦ ÿ =ML8NOö³´³ ¾ >wµ·µ ¾ >>{ƒ’ ‚…r‹y|{ŸsI‚…v4p‘w‡uIr Œ…y|{}plr>¢€}{Ÿy|‚…vxw‘€}†p‘›y|‰ ‚®ªp‘v|„$ÿ¤UX£Çx¨-±ªÿ(Ð ¢›ÿ¥{}†6{}rIŒg€}uA’R‚ ’G{}r‡y|‰ ‚=†—‚…yp‘ÿ¤UXQ¢’R‚…sAr ‚ ’c{}rÒ³·³ ¾ ¢›½®‰ ‚Œgplr †œyxw‘r˜yu¨9v|‚…~ v|‚g†—‚gr˜y|†4y|‰I‚{ƒ’ ‚…r‹y|{ŸsI‚…v4p‘s ¦+¨-±6ÿ¤QUXQ±V¨ ¡ ¦q¦I¤›w‘rA’ÒØzþh¥€}{Ÿy|‚…vxw‘€}†9†—{}r Œg‚¢È¢ÉIÊ ¸ µT> ¸ÌË&ͲΠµT>wGŒ…pl„)~›plr ‚gr˜y ¢wG~›pzv—y8p‘¥y|‰ ‚MŒgpl„)~›p‘rI‚gr˜yK¯ªuIrIŒ@y|{ƒp‘r›´ ¨ Á Çx¨-Ö4Ð ¢¯ªuIrIŒ@y|{ƒp‘r›´®{ƒ’ ‚gr˜y|{ŸsA‚@v|†4Öv|pl„ ¸ÌË&ͲΠµ ¾ ¯Ãµ¥°´×Mn=Ì ¾ ´@¢ZU ÁÇiUqÖ4ÐK{ƒ†3‹Ü ׻ѡÐqÒŸÏKÑ0Úlâ=ÙxÜ Ý3‹Ü Ï“â|ÏjÑ53‹Ü ×ÃÑq×»â¥3“×»âxСâ|ÏzÑ0Û…Ñ0ÒŸÜ Ï úy|{}plrA´®{Ö’R‚gr˜y|{ŸsA‚…v ¤eþ){ƒ†Cw‘r¢wzy—y—v|{}IuRy|‚p‘y|‰Awjy8Œgpl„)~›p‘rI‚gr˜yK¯ªªu rIŒ…Žy|{}plrA´@¤AwzrA’ÄØ){}†4y|‰ ‚Kw‘Œ…y|uIw‘€2Šlwz€}uI‚Mpzy|‰I‚wjy—y—v|{ƒ u y|‚l¢×»ß“â|×»çªòŸÜ ã ÒŸÙáÒÑ¡Ú Ð¡â—ѦâazÑ0â|Ï“Ð¡ÒŸÜ Ï ÛgÏ“ß ÒŸÏzÑ¡â|×x3lסâ—Ñ¡âxßÔÓlÏ“Ù—Ñ0ÒŸÜ ÏлälÝ·{RÜ òŸÐxú W Ú“â6Ñ0â|×»ÝMç±ß“â¥3lÑ¡ÚÒŸÐe×»âxлÑ0×»ÒŸÙ—Ñ0â|ßKÑ0Ü8Ûqù¨a‘â|ßKÏ‘Ó“Ý·{‹âx×סâ|лÑ0×»ÒŸÙ—Ñ0â|ߨù˜×»Ð¡Ñ»ç±ÜÒŸÏ‡Ü ×»ß“â|×Ñ0ÜMÛgÐ0Ð0Ólסâ=ß“â|Ù|ÒŸß“âxÛ`{“ÒŸòŸÒѱäjú˜à6ß“ß“ÒÑ¡ÒŸÜ Ï˜ÛgòŸòäKß“Ü ÝKÛgÒŸÏKÐx3Râ|Ù|Òù˜Ù4ÛbazçÒŸÜ ÝÐ=Ûg×»âKÛgß“ß“â|ßIåAâ úã“úIÜ Ï“â 3‹Ü ×»Ñ8ÙxÛgÏÜ ÏlòäT{Râ9ÙxÜ ÏlÏ“â|Ù|Ñ¡â|ßÑ¡Üžâa“ÛgÙ—Ñ¡òäÜ Ï“â=ÜgÑ¡Ú“â|×&3‹Ü ×ÃÑ@úã â|Ï“â|×0Û…Ñ¡â|߇ӓСҟϓã=Ñ0Úlâqß“Ü ÝKÛgÒŸÏMßlâxСÙ|סҥ3lÑ¡ÒŸÜ ÏedСâ|âj}î-€˜ÔÖÜ ×eÝÜ ×»â•ßlâ|Ñ0ÛgÒŸòŸÐfœúûRÀ

o 3JIZ®O‹: 3JIZ4Bœ58D³>‚@y ÈqÏ̾ {4›‚y|‰I‚%£Tqr4st,4'uv'5¡w8xy*"uvz0%"uv,4*v9 ¡4¡ ÿ?È ¦©¨…ÿ ¡ ¦bºq¤UXb}}T~)p‘eŒgplrRsAt‘u vxwzy|{}p‘r¢„)p‹’ ‚g€b¤R–4‰ {}Œ@‰c{ƒ†|| ¦©¨…ÿ ¡ ¦¬ÿ¤UXQ¢ˆ–4‰I{}Œx‰wzv|‚¨’ {Ÿv|‚gŒ…y|€Ÿ ¼p‘v§y—vxw‘rI†—{Ÿy|{}Š‹€Ÿ{}rIŒg€}uA’R‚g†Ky|‰I‚s ÿxXQ¢|¤lw‘rI’KŒ…plrIr ‚gŒ…y|‚ ’ URþ£xÿv ¡ sV¥X-h}þ‘ÿ ¡ ¦q¢|¢zµIu v—ŽŒgp‘v—v|‚…†—~›plrA’R{}rIt‡þ‘ÿ±ÿQ|| ¡4¡ ÿ ¸ ¡£Y U ¡ ¦IXQ¦ ÿ¥ºq¤QUXb}} X-hiXl¨…ÿv¨`§X¥k U Y XQ¦Iÿq¯±†—‚g‚®µ¥{}t‘u v|‚8‘´@¢„„Œ$ %('q)+*Q,eŽq0 ҟлÑ0×»Ò¥{“ÓlÑ¡ÒŸÜ ÏGÜgÔPÔÖÓ“Ï“Ù—Ñ¡ÒŸÜ Ï˜Ûgò›Ûg׻ٜړÒÑ¡âxÙ—Ñ¡Ó“×»âxÐt‘uI{}†—‰I‚…†e›‚…y¡–®‚g‚grK’R{ŸÇP‚…v|‚gr˜yeŠ‘wzv|{ƒwzI€}‚g†epzRplrI‚Œgp‘„)~›plrI‚…r‹y–˜ ªu rIŒ…y|{}plr‚cu †—‚¨y|‰ ‚¨pl€}€}p –4{ƒr t¼†—‚…yžp‘CŒgplr †œy—vxw‘{}r˜yžŠ‘wzv|{ƒw‘ €ƒ‚…†ž{}r¬pzvx’ ‚…vGy|p=‚’Rp*rIp‘yGtlp{}r‹y|p*ªuRv—y|‰I‚…vž’ ‚…yxwz{}€ƒ†Gplry|‰I‚ˆy—vxw‘rI†—€ƒwjy|{ƒp‘r.pzCy|‰ ‚=(jý‹ÿ¢¨wzv|‚¨pl~Ry|{ƒp‘rAwz€={ƒr#y|‰ ‚ˆsIrAwz€®ŒgplrRsAt‘u vxwzy|{}p‘rŽCy|‰I{}†GŒx‰Ip‘{}Œg‚c{}†h¡ ¦ ÿv s ¡ oh ijý‹ÿ¢ Á ¢=µ p‘vž†—{}„)~ €ƒ{}Œg{Ÿy¡ –®‚¨pl„){ŸyGy|‰ ‚cŒ…p‘v—v|‚…ŽŠ‘wzv|{ƒwzI€}‚~sáþ#œ¥Ü¥à Ü»áxÙvâ(ã á§äiÜ»åóæ¥ã Û-ç:ÜèlÙ?äþž ßÜ¥à ܧá§Ùvâ(ã á§äiÜ»åóæ¥ã Û-ç:Üè»Ùñ-é›á œià ã ề ëlÙÝäþb ßQà ã ê4ë»ÙÝvñ-é ›á¥œ?ì¥ílÙ?ÙÜ¥â Úläþž ß`ç:Ü»ð-ã æ-çKäì¥ílÙ^Ù^Ü¥â¥Ú§éà ílâ(êܧäì¥ílÙ^Ù^Ü¥â Úñ`é›á¢œ?ì¥ílÙ?ÙÜ¥â Úlä(î^æ-è¥áxÙã ï`èläþž£ß-ç:Ü»ð`ã æQç:äìlí¥Ù?ÙÜ¥â Úlä(î^æ-èlá§Ùã ï`è-é›í¥â¥êܧäì¥ílÙ^Ù^Ü¥â¥Úlä(î^æQè¥á§Ùã ï4è¥ñóò8Öy|‚…v¥‰Iw ŠR{}r tC’R{}†œy—v|{ƒ u y|‚ ’My|‰ ‚•Œgp‘r sItlu vxwjy|{}plr§”Rr p –4€ƒ‚g’ tl‚˜ ‚…š‹ŽàÏ´¢¤§¦©ẍý ¡ ¦ ¡£ ¢Ì|þ¨zÿ—þ¨§¦K~ v|pl~›p‘†—‚ ’˜ G¿Å‹ÀgÁ“{ƒ†¥w‘r§w‘€}tlpzv|{Ÿy|‰I„lights-functionŠcar‹manufacturermotor-functiontransmission-function‚…€ƒ‚…Œ…y—v|{}Œ‚ «˜uI{}~I„)‚gr˜y=†—u ~I~ €ƒ{}‚…v ¤Iw‘rI’¨y|‰ ‚M„)p‘y|pzv—Ž¡u rI{Ÿy4†—uI~ ~I€}{}‚…v‰‘¢y|‰I‚g†—‚8€}{Ÿy|‚…vxw‘€}†g¢ Ä’ {}†œy—v|{}IuRy|‚ ’)ŒgplrRsAtluRvxwzy|{}plr2¤“–4‰I{}Œx‰ˆ{ƒ†qŒgplr †—{ƒ†œy|‚…r‹yw‘rI’ˆŒ…pl„)~I€}‚…y|‚4–¢v ¢y ¢˜y|‰I‚C’ pl„ˆwz{}rˆ’ ‚g†—Œ…v|{}~Ry|{ƒp‘rwzrA’žy|‰I‚8Œgu †œy|pl„)‚…vŒelectricequipmentsupplierbattery-function‹motor-unitsupplierv|‚ «˜uI{Ÿv|‚g„)‚gr˜y|†g¤R{}†4Œ w‘€}€}‚ ’¢wJg þh W ³ ¢|ÿQ ÿxX Wĸ ¡ ¦4¹: œþ‘ÿ ¡ ¦ ¢­ rKp‘vx’ ‚@v¥y|pCŒgw‘€}ŒguI€ƒwjy|‚q†—pl€}uRy|{ƒp‘rI†¥p‘vw4tl{}Š“‚gr§’ {}†œy—v|{}IuRy|‚ ’ŒgplrRsAtzŽu vxwjy|{ƒp‘r‡yxwz†—”M–®‚®‚g„)~ €}pj )þ£¢¥¤£¦+ẍý ¡ ¦ ¡£ ¢j|þ¨zÿ—þ¨§^¦¨¿Å‹À…Á»¤j–4‰ {ƒŒx‰p‘ÇP‚…v|†cy|‰I‚Aw‘†—{}†p‘v*›p‘uIrA’R‚ ’¢¾’ ‚@yxw‘{}€}‚ ’.’R{}†—ŒguI†—†—{}plr.plry|‰I{}†‡y|p‘~I{}Œ¢Œ wzr.›‚ˆªp‘uIrI’{}r#¿Å£¬‘Áä¿}À ÂzÁ»¢2½®‰ ‚‡pl€}€}pj–4{}r t¢Šlwjv|{ƒw‘I€}‚g†Cv|‚g~ v|‚g†—‚…r‹y9y0 R~›‚KŠlwjv|{ÖwzI€}‚g†’R‚…v|{}Š“‚ ’#v|p‘„y|‰I‚¢Œgp‘r sItlu vxwjy|{}plr^„)p‹’R‚g€4p‘Cy|‰I‚¢‚g€}‚gŒ@y—v|{ƒŒ'‚g«‹u {}~ Žy|‰ ‚M‚g€}‚gŒ…y—v|{}Œ‚ «˜uI{}~ „)‚gr˜y®†—uI~ ~I€}{}‚…v4y—vxw‘r †œª‚…v|†=y|‰I‚9Awzy—y|‚@v— cŒ…plr ŽsAt‘u vxwzy|{}p‘r¬yxwz†—”y|p*y|‰I‚c„)p‘y|pzv—Ž¡u rI{Ÿy‡†—uI~I~ €}{ƒ‚@vˆ‹ ~ v|pjŠ‹{Ö’R{}rIt*y|‰I‚{±¢‚‘¢„)‚…r‹y®†—uI~I~ €}{ƒ‚@v ¤I‚l¢tR¢Iy|‰I‚Š‘wzv|{ƒwzI€}‚T|þ‘ÿ±ÿxXQQ¤£ Á Œ wzr¢›‚{}rI†œyxw‘r˜y|{ƒwzy|‚g’…engine1..1motor-unit† €€1..1transmission–4{Ÿy|‰ Y X W ZY §|þ‘ÿ±ÿxXQ¤*p‘vuh}þ£vX-x|þ‘ÿ±ÿxXQQ¤z¢µ u v—y|‰I‚@v|„)p‘v|‚jsQ ¡ ¦Iÿv s ¡ ŒgplrRsAt‘u vxwzy|{}p‘r){ƒrRªpzv|„ˆwzy|{}plržy|‰Rv|pluIt‘‰Gy|‰I‚®uIr Œ…y|{}plrAwz€Awjv|Œ@‰ {}y|‚…Œ…y|u v|‚p‘¥y|‰ ‚Awjy—y|‚…v— ˜¢v|‚…~ v|‚g†—‚gr˜y|‚ ’¦‹ y|‰I‚ˆ’Rpl„ˆwz{ƒr§`h ijý‹ÿ¢ s ¦©¨…ÿ ¡ ¦±´¦ ¡ Øzþh Xš¼p‘=y|‰ ‚90bhpƒ55bhp1..1‡battery-function‚automaticmanualáŸ%œ î?â¥ï4è»Ù^ä(î(ïQê¥ä^à ã ê4ë»ÙÝäþb ßlî?â(ï`èlÙ?äiî(ïê¥äà ã ề ëlÙ^Ýxé+è¥ï% ¥íQà æ¥Ülñ-é›á¡œià ã ề ëlÙÝä(î^æQè¥á§Ùã ï4è»äþbß-à ã ề ëlÙ^Ýäiî^æQè¥á§Ùã ï4èQéèlï ¥íQà ælÜlñ`é›› á©%œ?ë¥Ü§íðä^à ã ê4ë»ÙÝäþž ß`ëlÜ»í¥ðQä^à ã ề ëlÙÝvñ-醗~›p‘rA’R{ƒr tžwjy—y—v|{ƒ u y|‚KwzrA’c~›pzv—y8Šlwjv|{ÖwzI€}‚g†g¢€120bhp„large-battery-functionmedium-battery-functiontwzrA’*{}r‹y|‚…t‘vxwzy|{}r tcªu rIŒ…y|{}p‘rAw‘€wjv|Œ@‰ {}y|‚…Œ…y|u v|‚g†G¯±plr¦ẅ Œgp‘r ŽŒ…‚g~ y|uIw‘€A€}‚gŠ“‚…€´¥–®‚C„Gu †œyq’R‚…sAr ‚=v|uI€}‚g†•p‘vq‰Ip –^y|pKp‘v|tlw‘r {ƒ…‚Cy|‰I‚8€}p‘ŽŒx‰AwzrIt‘{ƒrŒgw‘€PŒgplrRsAt‘u vxwzy|{}p‘rc”‹rIp –4€}‚ ’Rtl‚M{}r¨p‘vx’ ‚@v®y|p‡‚…„)~I€}p ˆw‘†œ RrIŒx‰ v|p‘rIp‘uI†%i')+*-,yˆ©0 αÝ3‹Ü ׻ѡâ|߇ÔÖÓ“Ï“Ù—Ñ0ÒŸÜ Ï“Ûgò›ÛgסÙ0Ú“ÒÑ0â|ٗѡӓסâCÜgÔ2ÝÜgÑ0Ü ×Ãç±Ó“Ï“ÒÑÙ|Ü Ïlù˜ã ӓסۅÑ0Ü ×$u v—y|‰I‚@v|„)p‘v|‚l¤y|‰ ‚‚g€}‚gŒ…y—v|{}Œ'‚ «˜u {ƒ~ „)‚gr˜yž†—u ~I~I€}{}‚…vˆ‚…šR~›pzv—y|†žy|‰I‚µtKp‘v=Œgw‘€}ŒguI€ƒwjy|{ƒr tGwK†—pl€}uRy|{ƒp‘r¨p‘v4wKtl{}Š“‚…rc’R{}†œy—v|{ƒ u y|‚ ’Œ…plr sItluRvxwzy|{}plryxwz†—”›¢Iw‘Œx”˜y—vxw‘Œx”R{}rŒgw‘€}ŒguI€ƒwjy|{ƒr t †—p‘€}u y|{}plr †¦ªpzv#’R{ƒ†œy—v|{} u y|‚ ’ Œgp‘rI†œy—vxwz{ƒr˜y¼†|wzy|{}†œ±wzŒ…y|{}plr~Rv|pl €ƒ‚…„)†‡¯‚Kn=ÌZX£†x´@¤A–4‰ ‚…v|‚§~ v|pl €}‚g„Šlwjv|{ÖwzI€}‚g†wjv|‚G’R{}†œy—v|{ƒ u y|‚ ’ªu rIŒ…y|{}plrIw‘€‡wzv|Œx‰I{Ÿy|‚gŒ…y|uRv|‚úh ijý‹ÿ¢ s ¦©¨…ÿ ¡ ¦©y|p¬y|‰I‚Œgwzv„ˆw‘r‹u ªw‘Œ…Žwz„)plr t#~ v|pl €}‚g„ †—p‘€}ŠR{}r t.wztl‚gr˜y|†w‘rA’Ä‚ wzŒ@‰Nwztl‚gr˜y‰Aw‘†c‚…š w‘Œ…y|€Ÿy|u v|‚…v ¤q{±¢‚‘¢®y|‰I‚*Œ wjv¢Œgp‘r sAt‘u vxwjy|p‘v¢{}†ˆv|‚g†—~›plr †—{}I€}‚¦p‘v¢Œ…pl„)„Gu rI{ŸŽÊ w‘Œx‰^wztl‚gr˜y)‰Iw‘†)w*uIr {ƒ«‹u ‚ˆ~ v|{}p‘v|{Ÿy0 ˜¢•nqp‘rI†œy—vxwz{ƒr˜y|†wjv|‚¢’R{}v|‚…Œ…y|‚ ’›‚…y0–q‚g‚gry|‰I‚Š‘wzv|{ƒwzI€}‚g†){}r¬y|‰ ‚†—‚gr †—‚cy|‰Iwzy)p‘rI‚pzp‘rI‚cŠlwjv|{ÖwzI€}‚l¢wzy|{}r t¼v|‚ «˜uI{Ÿv|‚g„)‚gr˜y|†‡Œgplr Œg‚…v|rI{}r t€}{ƒt‘‰˜y|†žy|p¼y|‰I‚c‚g€}‚gŒ…y—v|{}Œ'‚ «˜uI{}~ Ž„)‚gr˜y4†—uI~ ~I€}{}‚…v ¢Aµ¥{}rIw‘€}€Ÿ ˜¤Iy|‰I‚CªuIr Œ…y|{}plrIw‘€¥wjv|Œ@‰ {Ÿy|‚gŒ…y|u v|‚p‘v8ŒgplrRsAtzŽŒy|‰ ‚=Œgplr rI‚gŒ@y|‚ ’)w‘t‘‚gr˜y|†•{}†6y|‰I‚Øzþh Xj¢-XQ¦ W ^¦žþ4XQ¦ ÿ4¯Ãw‘tl‚…r‹y ¤‘–4‰I{}Œx‰v|{}rIt¢w YS¡ ÿ ¡ - ¦qªÿ)¯ Yu¡ ÿ ¡ Q ¦ªÿv s ¦+¨…ÿ ¡ ¦2´{}†‡‚@š ~›pzv—y|‚ ’y|pcy|‰I‚Œ wzv—Ž»„ˆwzrRuR±wzŒ…y|u v|‚…v ¢ µ¥{}tluRv|‚§Ë§t‘{ƒŠl‚g†8w‘rpjŠ“‚@v|ŠR{}‚…–Npz¥y|‰I‚M’ {}†œy—v|{}Iu Žu¤S¥•ÜgÑ¡âqÑ¡Ú˜Û…ÑÑ¡Ú“â®ÔÓlÏ“Ù—Ñ0ÒŸÜ Ï˜ÛgòIÛgסÙ0Ú“ÒÑ0â|ٗѡӓסâ|ЕÜgÔAÑ0Úlâ=ÝÜgÑ0Ü ×Ãç±Ó“Ï“ÒÑ¥ÙxÜ Ï‘ù˜ã Ólç×0Û…Ñ¡Ü ×ÛgÏ“ßCÑ0Ú“âÙxÛg×eÙ|Ü Ïlù˜ã Ól×0Û…Ñ¡Ü ×ÛgסâÏ“ÜgÑK3˜Ûg׻ѥÜgÔRÑ¡Ú“â 3“×»âxСâ|ÏzÑ¡â|ßGè'¦y§ÝÜ‘ßlâxòŸÐxúy|{}plr§p‘IuIr Œ…y|{}plrAwz€Rwzv|Œx‰I{Ÿy|‚gŒ…y|uRv|‚g†›‚…y0–q‚g‚grKy|‰I‚•Œ wzv6„ˆwzrRuR±wzŒ…y|u v|‚…v ¤û“Å

¥Ð  ½®‰ ‚grG‚gw‘Œx‰‡Š‘wzv|{ƒw‘ €}‚Rgú¿µgn{4{ƒ†‚…Šlwz€ƒuIwzy|‚ ’K˜ Œgp‘r sAt‘u vxwjŽy|pzv&²Çx¨´¦¢xÿœþ£¦ ÿ XQØzþh þ‘ÿ¦¨ ¡ ¦`¹b —þ‘ÿ ¡ §Ð ¤“{±¢‚l¢z{}†¥v|‚g~ v|‚…†—‚gr˜y|‚ ’¡OKJ d JH:c P H a¼k CIHr¬ a O hzi f C hzd$­e³>‚…yQg { ›‚9y|‰I‚C†—‚…y=p‘¥Šlwjv|{}ŽR¢iq]þ4XQ¦ ÿ«ªØ4oX@üSp‘¨ ¡ ¦4¹b œþ‘ÿ ¡ S'y|‰ v|p‘uIt‘‰wŒgp‘~˜ ¦pzQg2¤>–4‰ {ƒŒx‰Xlk U Y XQ¦ ÿ¢Œgp‘r sAt‘u vxwjy|p‘v”‹rIp –4€}‚ ’ t‘‚#Aw‘†—‚#{}r Œg€}uA’ {}r t^Š‘wzv|{ƒw‘ €ƒ‚…†Á ±:xþzÿ±ÿxXQQ¤£ Á ±ýX|þ W xh (jý‹ÿ¢ Á ±bh ijý‹ÿ¢ Á ´@¢×9pMuIrIŒ@y|{ƒp‘rI†•wzv|‚4‚g€}‚g„)‚gr˜y¾¾{}~I„)‚gr˜y®Œ…plr sItluRvxwzy|p‘v È„)‚…r‹y|†•y|pGy|‰I‚M‚…€ƒ‚…Œ…y—v|{}Œ§‚g«‹uï`èläþé ç:Ü»ð-ã æ-çKäì¥ílÙ^Ù^Ü¥â¥Úlä(î^æQè¥á§Ùã ï4è¥õõ§òµIuRv—y|‰I‚…v|„)pzv|‚l¤ey|‰ ‚c‚g€}‚gŒ@y—v|{ƒŒc‚ «˜uI{}~I„)‚…r‹y‡Œgp‘r sAt‘u vxwjy|p‘vGv|‚…Œg‚g{}Š“‚g†ïžÃÄôôìlílÙ^ÙÜlâ¥Úlä(î^æ-èlá§Ùã‚9ªp‘€}€ƒp –4{}rIt)v|‚ «˜u {}v|‚…„)‚gr˜y|†qv|p‘„y|‰ ‚MŒ wjvCŒ…plr sItluRvxwzy|p‘v Èy|‰ã ề ëlÙ^Ýä(î^æ-è¥áxÙã ï`èläþQéZà ã ê4ë»ÙÝä(î^æ-èlá§Ùã ï`èõõ§ò½®‰I‚‚…€ƒ‚…Œ…y—v|{}Œ§‚g«‹u {}~I„)‚gr˜y®Œ…plr sItluRvxwzy|p‘v8y—v|{}‚g†=y|pžŒ wz€ƒŒ…uI€ƒwzy|‚§wž€}p‘ŽïžÃÄôôà ¦+¨…ÿ ¡ ¦ ¥Xlk lXQ¢ w£h}þ£X-§|þ‘ÿ±ÿxXQ¤Œgp‘„)~›plrI‚…r‹y ¤‡–4‰I‚…v|‚gw‘†.y|‰ ‚sX W Y x|þ‘ÿ±ÿxXQQ¤£ s ¦©¨…ÿ ¡ ¦©v|‚g«‹u {Ÿv|‚g†¢w Y X W Y §|þ‘ÿ±ÿxXQ¤ÄŒgp‘„)~›p‘ŽY|þ‘ÿ±ÿxXQ¤£ s ¦+¨…ÿ ¡ ¦I¢q½®‰I‚¨rI‚@– ªu rIŒ…y|{}p‘rAw‘€®v|‚g«‹u {Ÿv|‚g„)‚gr˜y|†Gwjv|‚cŒ…pl„žŽ¡ ¡4¡4W v|‚gŒgpzvx’ {}rIt'{}†K€}{}„){}y|‚g’w‘†§„Gu Œ@‰¦w‘†§~›pl†—†—{}I€}‚l¢µ p‘v8‚ w‘Œx‰'Œgp‘r sAt‘u vxwjy|p‘vC{}yC{}†C†—u3h)Œg{}‚gr˜y4y|p)†œy|p‘v|‚Kplr €Ÿ ¢plrŒgw‘†—‚)–4‰I‚…v|‚²¦¡ ¡4¡4W ‚S¦¡ ¡4¡4W ¢Gwzv|‚žr ‚g‚ ’ ‚g’'y|pcw Š“pl{ƒ’ẅ †—u I†—‚ «˜u ‚gr˜yMwz†—†—{ƒt‘rI„)‚gr˜ypz•y|‰ ‚¦¡ ¡4¡4W ¢4{}†qw‘rIpzy|‰I‚…v•†—pluRv|Œg‚4p‘2‰I{}t‘‰)Œgpl„)~ u yxwzy|{}p‘rAw‘€ Œgpl†œy|†g¢y|{}p‘r)p‘ö¦¡ ¡4¡4W ¢§rI‚…‚ ’'rIp‘y9›‚‡„){}r {ƒ„ˆwz€±¤A{±¢‚l¢›ªpzvMy|‰I‚T¦ ¡ ¡4¡4W tl‚…rI‚…vxwjy|{ƒp‘rÊÁÀÁ½w‘€}€Ÿ ^Œx‰AwzrIt‘‚g†Gy|‰I‚cŠlwjv|{ƒw‘I€}‚c{ƒr †œyxw‘r˜y|{ƒwzy|{}plrA´@¤•y|‰ ‚cpzy|‰I‚…vžplrI‚{ƒ†y|‰I‚¨€}p˜Œ¦q¢|ÿœþ£¦IÿVXQØzþh þ‘ÿ¦)þ4XQ¦Iÿ–4‰ {ƒŒx‰ˆ{}r ªpzv|„)†•y|‰ ‚8Š‘w‘€}u ‚8†—‚…rA’RŽ{}rItKw‘t‘‚gr˜y®wz›pluRyq€}p˜Œ wz€A{}rIŒgp‘rI†—{}†œy|‚grIŒ…{ƒ‚…†g¢ nq‰Aw‘r tl‚g†p‘2€}p˜Œ wz€›w‘†—†—{}tlrRŽ¡rI{}Œ wzy|‚g’cy|pcŒ…plrI†œy—vxwz{}r‹yM‚gŠlwz€}uAwzy|{}r tcwztl‚gr˜y|†MŠ‹{ƒw„)‚gr˜y|†9wjv|‚GŒgp‘„)„Gu8¨ž„)‚g†—†|w‘t‘‚g†g¤2{ƒr Œgplr †—{}†œy|‚gr˜yŠlwjv|{ƒw‘I€}‚Gw‘†—†—{}tlr „)‚gr˜y|†wzv|‚‡Œgpl„‡uIrI{ŸŽŒ wzy|‚g’*y|pˆŠ‘w‘€}uI‚‡†—‚grA’R{ƒr ẗ¡¡ ¡4¡4W „)‚g†—†|w‘t‘‚g†g¢r©qwjv|{ƒw‘I€}‚w‘tl‚…r‹y|†Š‹{ƒw²¦car configurator (a)½ok?lights-function-1...nogoodselectricequipmentconfigurator (c)motor- unitconfigurator (b)nogoodsbattery-function-1...agent_viewok?lights-function-1 battery-function-1Šlwjv|{ƒw‘I€}‚4{}rI†œyxwzr‹y|{ƒwjy|{ƒp‘rI†–4{}y|‰ˆ‰ {ƒt‘‰I‚…v•~ v|{}pzv|{}y¡ žŠ‘wzv|{ƒw‘ €}‚g†g¢Ê ¡ ¡4¡4W ¢battery-1lights-1Áelectric-equipment-1¿head-lights-1front-fog-lights-1w‘†—†—{}tlr „)‚gr˜y|†žp‘MŠlwz€ƒu ‚†—‚grI’ {}rIt¦w‘t‘‚gr˜y|†ˆwzv|‚¢†œy|pzv|‚ ’.{}r¬y|‰I‚€}p˜Œ wz€þ4XQ¦Iÿ«ª|Ø4oX@ü6¤–4‰I{}Œ@‰#{}†‡uI†—‚ ’¼y|p*Œx‰I‚gŒx”¦y|‰ ‚¨Œ…plrI†—{}†œy|‚gr Œ… pz9€}p˜Œ wz€v|‚g~ v|‚…†—‚gr˜yKŒgplrRÉA{}Œ…y|{}rItcŠlwjv|{ÖwzI€}‚){}rI†œyxwzr‹y|{ƒwjy|{ƒp‘rI†–4‰I{}Œx‰wjv|‚)Œ w‘€}ŒguRŽ‰I{}tl‰ ‚…v8~ v|{}p‘v|{Ÿy¡ ¨y|‰Iw‘rcŒgplr rI‚gŒ…y|‚g’Œgplr †œy—vxw‘{}r˜y8‚gŠlwz€}uAwzy|{}r t)w‘t‘‚gr˜y|†g¢%i')+*-,y©0 αÏjÑ0â|×ÃÔªÛgÙ|â8ÜgÔ>â|òŸâ|Ù—Ñ0×»ÒŸÙ4⥤‘Ó“Ò¥3lÝâxÏjÑÙ|Ü Ïlù˜ã ӓסۅÑ0Ü ×$rI{Ÿy4Œgp‘r sAt‘u vxwjy|p‘vCw‘rI’‚g€}‚gŒ…Žy—v|{}Œc‚ «˜uI{}~I„)‚gr˜y‡ŒgplrRsAt‘u vxwzy|pzv ¢£Mw Š‹{ƒr t¦Œgw‘€}ŒguI€ƒwjy|‚ ’‰Awz†¥w=†—‚…y>p‘ Šlwjv|{ƒw‘I€}‚g†2v|‚g~ Ž„)pzy|p‘v—Ž»uIr {ŸyCŒ…plr sItluRvxwzy|p‘v9Œgpl„)„‡uIr {ƒŒgwzy|‚g†4y|‰I‚ªp‘€}€ƒp –4{}rItcv|‚ «˜uI{Ÿv|‚…Žv|‚g†—‚…r‹y|{}r tžy|‰I‚Mªu rIŒ…y|{}p‘rI†g¤AŒ…pl„)~›plr ‚gr˜y|†g¤I~›pzv—y|†g¤›wzrA’¢wjy—y—v|{ƒ u y|‚g†y|{}p‘rŒgp‘r ªpzv|„y|p‡y|‰I‚Cv|‚ «˜uI{Ÿv|‚g„)‚gr˜y|†®pz¥y|‰I‚MŒgwzv8ŒgplrRsAt‘u vxwzy|pzv ¤ y|‰ ‚w‘€erIp‘yxwjy|{}plr>¢Å˜¢¯®GhpzpluRvC€}p‘tl{}Œh§P H a C¡°4± iIh§PiIbb] J d$­ ­ Iw®ªu rIŒ…y|{}plrIw‘€Rwzv|Œx‰I{Ÿy|‚gŒ@y|u v|‚p‘AŒ…plr Žc:JsItlu vxwjy|{}plry|p4y|‰ ‚6„)p‘y|p‘v—Ž»u rI{Ÿy‚ wzŒ@‰c~Awz{}v®p‘Œgp‘rIr ‚gŒ…y|‚ ’ˆŒgplrRsAt‘u vxwzy|pzv|†g¤ –4‰ ‚…v|‚wz€ƒ€PŠ‘wzv|{ƒw‘ €}‚g†=p‘Œ…plr sItluRvxwzy|p‘v Èï`èläþé ç:Ü»ð-ã æ-çKäì¥ílÙ^Ù^Ü¥â¥Úlä(î^æQè¥á§Ùã ï4è¥õoéè¥ïêï`ï`ðóôôìlílÙ^ÙÜlâ¥Úlä(î^æ-èlá§Ùãã ề ëlÙ^Ýäiî^æQè¥á§Ùã ï4è»äþQé à ã ê4ë»ÙÝä(î^æ-èlá§Ùã ï`èõõ§òôày|‰ ‚GŒgp‘rI†—uI„)‚@vM„Gu †œyM‰IwjŠl‚‡‰ {ƒt‘‰I‚…vK~Rv|{}p‘v|{Ÿy0 'y|‰Iw‘r'y|‰Ip‘†—‚žp‘•y|‰I‚uIŒ…‚…v ¢û‹¢~Rv|p‹’dgfghji+P H f Jv± i+] O i f4P H aAC©Hk CIHr¬ a O hjiIf C h‘d$­§³2‚…y§g¨{¼›‚*y|‰I‚Ç3³†—‚…y6pz›Š‘wzv|{ƒw‘ €ƒ‚…†•’R‚…v|{}Š“‚ ’Kv|pl„ uIr Œ…y|{}plrAwz€Iwjv|Œ@‰ {Ÿy|‚gŒ…y|u v|‚ÌÈqÏ ¾ { p‘Œgp‘r sItlu vxwjy|{}plr)„)p‹’ ‚…€I>{}„)~›p‘v—y|‚ ’§v|pl„ Œgp‘r sItlu vxwjy|{}plrž„)p‹’R‚g€©½®‰I‚K„)pzy|p‘v—Ž»uIr {}yCŒgp‘r sAt‘u vxwjy|p‘vM€}p˜Œ wz€}€} *†œy|pzv|‚g†Cy|‰ ‚\¦ ¡ ¡4¡4W w‘rI’Œgw‘€}ŒguI€ƒwjy|‚g†¨wzr%wz€}y|‚@v|rAwzy|{}Š“‚©†—p‘€}u y|{}plr2¤¢{±¢‚l¢Œx‰Ip˜p‘†—‚g†`y|‰ ‚ h}þ£X-{}ry|‰ ‚)þ4XQ¦Iÿ«ª|Ø4oX@ǜ p‘Œgp‘r sItlu vxwjy|p‘v z¢{ƒŒgwzy|‚ ’)y|pGy|‰I‚9‚g€}‚gŒ…y—v|{}ŒK‚ «˜uI{}~I„)‚gr˜yqŒgplrRsAtluRvxwzy|pzv È„‡uIrï`èläþé à í¥â¥êܧäì¥ílÙ^Ù^Ü¥â¥Úlä(î^æQè¥á§Ùã ï4è¥õõ§òïžÃÄôôìlílÙ^ÙÜlâ¥Úlä(î^æ-èlá§ÙãwzI€}‚g†§’ ‚…v|{}Š“‚g’*Öv|pl„%ªu rIŒ…y|{}p‘rAw‘€•wzv|Œx‰I{Ÿy|‚gŒ@y|u v|‚TÈÏS· { p‘qŒgplrRsAtzŽµ¥{}rAwz€ƒ€Ÿ ˆy|‰I‚C‚g€}‚gŒ…y—v|{}ŒM‚ «˜u {ƒ~ „)‚gr˜y®Œgp‘r sItlu vxwjy|p‘v4Œ wz€}ŒguI€ƒwzy|‚…†Cw§†—p‘ŽuRvxwzy|{}plr„)p‹’ ‚…€8¦‚…šR~›p‘v—y|‚g’¼y|pŒ…plr sItluRvxwzy|{}plr„)p‹’ ‚…€·Ço#³´ QЀ}uRy|{ƒp‘r¨v|‚…t“wzvx’R{}rIt‡y|‰ ‚8v|‚g«‹u {Ÿv|‚g„)‚gr˜y|†qpzey|‰I‚8Œ wjv4ŒgplrRsAtluRvxwzy|pzv4w‘rI’y|‰ ‚M„)p‘y|pzv—Ž»uIrI{Ÿy=Œ…plr sItluRvxwzy|p‘v ¢½®‰ ‚gr¨‚ wzŒ@‰¨Šlwjv|{ÖwzI€}‚¸g¿¹g { {ƒ†'v|‚g~Rv|‚g†—‚gr˜y|‚ ’N{}r¨y|‰I‚€}p˜Œ wz€{}†4uI~P’ wzy|‚ ’¨‹ ˆy|‰ ‚~Øzþh X|¢-XQ¦ W ¦\¨ ¡ ¦4¹b œþ‘ÿ ¡ /¢½®‰I‚#†—p‘uIrI’ rI‚…†—†¼wzrA’¨Œgp‘„)~I€}‚…y|‚gr ‚g†—†p‘¨w‘†œ Rr Œ@‰Rv|plrIp‘uI†AwzŒ@”˜Žy—vxwzŒ@”‹{}rItˆ{}†M†—‰ pj–4r*{}r#¿Å‹ÀgÁâ2½®‰I‚K–®pzv|†œy—Ž»Œ w‘†—‚Gy|{}„)‚KŒgp‘„)~I€}‚…šR{Ÿy0 ¢pzwz†œ RrIŒx‰ v|plr plu †žAwzŒ@”˜y—vxw‘Œx”‹{}rIt¼{}†)‚…šR~›p‘rI‚gr˜y|{ƒw‘€4{}r¬y|‰ ‚¢r‹uI„‡›‚…vGpzµ¥{}tlu v|‚ Ɔ—‰Ip –4†¨wÕ‚Kn=ÌŠ‘wzv|{ƒwzI€}‚g†g¢q½®‰I‚¢–®pzv|†œy—Ž»Œ w‘†—‚*†—~AwzŒg‚'Œgp‘„)~I€}‚…šR{Ÿy0 ¬’ ‚…~›‚grA’R†)plr.y|‰ ‚v|‚g~ v|‚…†—‚gr˜yxwzy|{}plr¤p‘v`y|‰I‚2X-hiXl¨…ÿv¨`N–q‚‚g„)~I€}p Äy|p^‰Iw‘rI’ €}‚r¦ ¡ ¡4¡4W ¢x¢M½®‰I‚p‘~ y|{}plr †¢vxw‘r tl‚Öv|pl„ uIrRv|‚g†œy—v|{}Œ…y|‚ ’Šlwjv|{}Žw‘ €ƒ‚…†¥’ ‚@v|{ƒŠl‚ ’9v|p‘„`y|‰ pl†—‚~Awzv—y|†>p‘‹y|‰I‚6Œgp‘r sItlu vxwjy|{}plrK„)p‹’ ‚g€ ¯ªv|‚g~ Ž½®‰p‘v=‚gw‘Œx‰ W ¿Ò³ ¡£Y ÇÅ

; º)ÇKºQÍ ¨ ºÎÇJºÓ6úvÔÛg×¡Þ â|×|å ú Óú3Õ2Ö 1 Ü Ï“Ï“Ü ×|å3דú ú3ÔÛgٜژÛgÏjÑxåIÛgÏlßØÓú3Ù‘Ü òŸÜxá6ÛxäjúÓra£3‹âx×ÃÑCСä‘СѡâxÝЮÔÖÜ ×=Ù|Ü Ïlù˜ã Ó“×¡Û…Ñ¡ÒŸÜ Ï*Û…Ñ ÒŸã ÒÑœÛgòªóÚ 1 ÕX¥`ÛgÏlßÑ{‹â—ç}ÐÏl€ÒÑ9úç-€êé4ú ð4ú8Ô¥Ü Ó“×»ß“âxÛgÓ*ÛgÏ“ßRÔqú ð8ú 1 ú 1 Ú“â|Ï“ã“úGàÄÔÜ ×»ÝKÛgò£Ù‘â|ÝKÛgÏjÑ0ÒŸÙ|Ð4ÔÜ ×}ßøÞvää–[ßøÞ ÷ å“ð$Ï åÐÏxïlóígî î–è£ ð$Ï å8Ïxî î ìlú} ï`€êÔqú 1 Ú˜ÛgÏlß“×0ÛgСâ|ÞgÛgסÛgÏIåzàCúžùqÜ‘â|òªå ÛgÏlßSúCú…Ϊá6ÛgÐ0ÛgÞ‘Òªú ® Ó“Ï“Ù—Ñ¡ÒŸÜ Ï˜Ûgòné6â¥3lç÷÷ ßøÞvää–[ßøÞ ÷ å£3˜Ûgã â|Ð:ïó–è‘ì ëlå0Ïxî î"çlúîâ#âݨä]"ÞÛr]"Þvà–Ý$[[óäÞn\tñ£ÞúæPú Ûgס׬ÛgÏ“ßSØ.úæ›úeԥҟ׻ÝÒŸÏ“ã Ú˜ÛgÝžúàqÏSàѡѡ׻ҥ{“ÓlÑ¡â|çþÙ£3˜ÛgÙ|âWóð$Ïè&ç ìlå¡Ïxî î ëlúå:îóñtÿ-åXæˆå0ÏxïlåÐÏß ÷ ä–Þvà#ä@å¨ïjïlå çlóðjížç–è&ç$Ïxðlå8Ïxî î ïlúîÞn\Åä–ýøý-€©àCú ® â|òÔÖâx׻ϓҟã“åùCú ® ×»ÒŸâ|ߓסҟÙ0ÚIå ÛgÏ“ß úv×jÛgϓϘÛgÙ0ÚIú®è'¦y§'ÛgÐqßlÜ ÝKÛgÒŸÏ}ô3ö¦¥§¥"ö©¨ åEÕq×ÃçåZ3˜Ûgã â|Ð:ç ì–èïjïlåÕq×»ò}ÛgÏ“ß“Ü“å ® òŸÜ ׻ҟߘÛlåÏxî î îlúY$]"[\£¯ô3ö¦¥§¥6ö©¨Õ“Ïlã СÑxú*à סâ|Ð¡Ü Ó“×¡Ù|â—ç{˜ÛgСâ|ßF3˜ÛgסÛgß“ÒŸã Ý}ÐÏxï-€¼¦úð•â|ҟϓ׻ҟٜÚÛgÏ“ßìÓúجú4×Û0å:îóågå3˜Ûgã â|Ðqð ìjíè‘ð ëžï“å3¦žÒ}ÛgÝÒªå ® §eå˜è:Ù‘àCåÏxî î$Ï úÜ ×¡ÝKÛgò‹à&33“×»ÜjÛgÙœÚÑ0Ü Ü ÝKÛgÒŸÏlçóÕq×»ÒŸâ|ÏzÑ¡â|ّ߯Ügԃѱá6Ûgסâ â|Ð0ÒŸã ϵÓ2Ïzé‘Òç®ßøÞvää–[ßøÞ ÷ Ûr]"Þ–^%ä[äÞvàä@åó3“Ûgã âxÐ4ïó–è‘ìjí‘å¦žÜ ÏzÑ¡â|×»äjå 1 à8åjèXÙzàCå¨Ïxî îžï“ú÷å:îóñtÿ-åXæyüôY$ä#à–ß«Z6ý&îââÝ$ä#"”Û]"Þ ÷ Ý$[óZ"\Åßá]"ÞÿSäâß ÷ Þ˜å$Ïxðlå ï“ó ç"ç"ç–è&çžï"ï“åå â—Ñ¡×¡Ü ÒÑxå3¦žÎœå0Ïxî4 îlúÏ%ïjï$Ï÷ Z'ßøÞvä@å0Ïxðlå çló ç ë–è‘ì ëlå8Ïxî î$Ï úå:î:æ@ZZeòväà%ã&Þv]"ý ] ÷ *ÿCZ§*"â0å£3“Ûgã âxÐEÏ î–èvÏxî ëlånÙlÛgÏ“ß“Úzӓ׻СÑxå˜èqñ9åvÏxî î4lúÿSZ"\ß«Þ ÷0 Z"Þ ÷ ݨZ ÷ ä1¡£ä ^ä–[óä–ÞvàäEæ@Z"ÞnݨZ"ýú>à6ß“ß“ÒŸÐ¡Ü ÏlçªØ¨â|Ð0òŸâ—äjå¡Ïxî î4lúä–ýß«Þ¯ÿSä–âß ÷ Þ$üSý Ý$õä–[-å'àZ§6ä–Üß«àEë£Ý2(%ý ßøâã$ä–[—å§3˜Ûgã â|ÐEÏ"ç–è‘ð ï ïlåÏxî îžï“ú÷ Ý&[Z"\Åß«]"ÞJÿSäâß ÷ Þ˜åCÏxðlå:ï“ó ç ïjíèå:îóñtÿ-åXæyüÌôY&äàßáZ"ýXîââ#ݨä#"yÛr]"Þð ïlå3Ù‘â¥3Iú¡Ïxî î4lú ç]"Þ3SÞv]"õ-ý ä ÷ äZ"ÞµÿSZ"\ Zñ-Þ ÷ ß«Þvä#ä–[ßøÞ ÷ å3Ïxïlåìlóëjížç–è‘ë4 ìlårÏxî î4lúR†œy|‚g„)†¥v|‚ «˜uI{Ÿv|‚®y|‰I‚=~Rv|pjŠR{}†—{}plr)pz›„)‚…y|‰ p‹’ †ªpzv®’R‚g†—{}tlrI{}r tMŒgplrRsAtzŽu vxwjy|{ƒp‘r¢”‹rIp –4€}‚ ’ t‘‚KAw‘†—‚…†8p‘r'wž‰I{}t‘‰I‚…v8€}‚gŠ“‚g€2p‘wzI†œy—vxwzŒ…y|{}plr*w‘€}†—p†œ‚…v|†œyxwzrA’IwzI€}‚M˜ ˆy|‚gŒx‰IrI{}Œ wz€>‚@š ~›‚@v—y|†g¢½®‰ ‚ w‘uRy|pl„ˆwjy|‚ ’"t‘‚grI‚@vxwzy|{}plr p‘©€}plt‘{}Œ…Ž»Aw‘†—‚g’ ’ ‚g†—Œ@v|{ƒ~Ry|{}plrI†uIrI’äjÜ Ï“ßIúSÛr]6Ü2ÜÝ&ÞnßáàZ"\Åß«]"ÞnâS]#^E\«ã$äCåÛ¡æˆånç ðlå¨çlóð î4–è&ç$Ïlå8Ïxî4 îlú}ð-€êé4ú דú”ÔÛ|äzÛgסßlÜcÛgÏlß úæ›ú”¦žÒŸ×0ÛgÏlÞ âx×|úˆà`ÙxÜ Ý3lòŸâ%a‘ÒѱäÛgϘÛgòälСҟÐCÜgÔy|‰ v|p‘uItl‰ˆy—vxw‘r †—€ƒwzy|{}plr¢pz’Rpl„ˆw‘{}r¨†—~›‚gŒg{ŸsAŒ„)p‹’R‚g€}{}rIt§Œgplr Œg‚g~ y|†=‚@šRŽÐ§3˜ÛgÙ|â—ç{‹Ü Ó“Ï“ßlâxß¼òŸâ@Ûg׻ϓҟϓã¢ÛgòŸã Ü ×¡ÒÑ¡Ú“ÝÐMÔÖÜ ×MÑ0Ú“â)Ù|Ü Ï“Ð»Ñ0סÛgÒŸÏjÑGÐ0Û…Ñ0ҟлç~ v|‚g†—†—‚g’c{}r¨y|‚@v|„)†®p‘¥w‡†œyxw‘rI’Iwjvx’c’R‚g†—{}tlr€ƒwzrItluIw‘t‘‚€ƒ{}”“‚9°²¢³*‰Aw‘†ÔªÛgÙ—Ñ¡ÒŸÜ Ï 3“×»Ü4{“òŸâ|ÝžúαÏìë£[]àží-å'å:å'î—åI3˜Ûgã â|ÐKð î4–è&ç ïžï“åeæ›Ü ׻ѡò}ÛgÏ“ßIåÕqסâ|ã Ü ÏIå8Ïxî î ëlú’‡†—p9±wjv ¢‹nqpl„)~IwzvxwzI€}‚®v|‚g†—‚ wjv|Œ@‰ž‰Iw‘†›‚g‚…rž’ p‘rI‚{}r¢y|‰I‚sA‚g€ƒ’R†9p‘•wzu y|pl„ˆwjy|‚ ’'w‘rI’¢”‹rIp –4€}‚ ’ t‘‚…Ž»Aw‘†—‚g’*†—pzy¡–=wzv|‚‡‚gr ŽrIpzy6›‚g‚grž’R{}†—ŒguI†—†—‚tl{}rI‚…‚…v|{}rIt*¿ƒÀ‘ÀgÁâ ­ r¿û‘Á6wžp‘v|„ˆw‘€†—‚…„ˆw‘r˜y|{}Œg†Cp‘vMp‘Zp0‚gŒ…y„)p‹’R‚g€’R{}Žw‘tzvxw‘„)†8Aw‘†—‚g’plrÒn²¢½N{}†9’R‚…sAr ‚ ’c{}r'p‘vx’R‚…v4y|p)†—uI~ ~›p‘v—y4y|‰I‚Kwz†œŽÕ5{lõ»â|Ù|Ñr¦žÜzß“â|ò Ò}Ûgã ×0ÛgÝÐxú&îññ4ñJòn[óZ"ÞnâZ6à–\Åß«]"Þnâ-]"Þô]#^\ÅõZ"[ätñ-Þnö‚§ŠR{}‚…–¨pluRv9–®pzv|”'w‘†Œgpl„)~ €}‚g„)‚gr˜yxwzv— )†—{}r Œg‚MpluRv4tlplw‘€2{ƒ†=y|‰ ‚9tl‚…rI‚…vxwjy|{ƒp‘r¢p‘e‚…šR‚gŒguRyxw‘I€}‚†—‚g†—†—„)‚gr˜yCp‘v|‚ «˜uI{Ÿv|‚g„)‚gr˜y8†—~›‚gŒg{ŸsAŒgwzy|{}plr †g¢ =סâ|СâxÏjÑ0Û…Ñ0ÒŸÜ Ï¬ÛgÐ â|Ð0ÒŸã ÏûéÛ…Ñ0ÒŸÜ Ï“ÛgòŸâjú?îññ4ñ(Ûr]"Ü:YvÝ$\Åä–[#üôY&äà–ß«Z"ý€}pltl{}Œ§’ ‚…†—Œ…v|{}~ y|{}plr †g¢}ì-€8rcpjŠ“‚@v|ŠR{}‚…–Np‘r¢wz†—~›‚gŒ…y|†4w‘rI’wz~I~I€}{}Œ wjy|{ƒp‘rI†4p‘>ªu rIŒ…y|{}plrIw‘€Pv|‚g~ Žéâ¥3“×»â|Ð0â|ÏjÑœÛ…Ñ¡ÒŸÜ ÏÛgÏ“ß¼à•òŸã Ü ×¡ÒѡړݾÔÜ × 1 Ü Ï“Ù|ӓ׻סâ|ÏjÑeÓ>Ïlã ÒŸÏ“â|âx×»ÒŸÏ“ã“úv|‚g†—‚gr˜yxwzy|{}p‘rI†¢{}†¢t‘{ƒŠl‚gr {}r©¿ lÁä=–4‰I‚…v|‚y|‰I‚*ªu rIŒ…y|{}plrIw‘€v|‚g~Rv|‚g†—‚gr Ž{˜ÛgÙœÞxõ¡ÓlÝ3“ÒŸÏ“ã“å2òŸâxÛgסϓҟÏlãÛgÏ“ß*Ù|ÓlÑ¡Ð0â—Ñß“â|Ù|Ü Ý3‹Ü Ð0ÒÑ¡ÒŸÜ ÏIúìå:[\Åß 4à–ß«Z"ýyxwzy|{}plrpz9w*’R‚gŠ‹{ƒŒ…‚¨{}†G’ {}Š‹{Ö’R‚ ’{}r˜y|p¢y|‰ v|‚g‚¨~Awjv—y|†g¢6½®‰I‚ˆ{}r˜y|‚grA’R‚ ’}ë-€êé4ú âxÙ0ÚzÑ¡â|×xúÓ>ÏlÚ˜ÛgÏ“Ù|â|ÝâxÏjÑ¡Ð¥Ð0ÙœÚlâxÝâ|Ð2ÔÜ ×2Ù|Ü Ï“Ð¡Ñ¡×0ÛgÒŸÏjÑG3“×»ÜzÙxâ|СÐ0ÒŸÏ“ã“órIŒ…y|{}plr2¤>y|‰ ‚ž†œy—v|uIŒ@y|u v|‚žpz=y|‰I‚)’R‚gŠ‹{ƒŒ…‚l¤¥wzrA’¦w¢’ ‚g†—Œ@v|{ƒ~Ry|{}plr‰ pj–y|‰I‚§’ ‚…ŠR{}Œg‚§wzŒ@‰ {ƒ‚…Š“‚g†CwGªuIr Œ…y|{}plr¢v|‚g~Rv|‚g†—‚gr˜y|‚ ’y|‰Rv|pluIt‘‰*wž~ v|p˜Œg‚…†—†ªu}íQ€êÔqú ® ÛgòÑ¡ÒŸÏ“ã Ð@å¨Óú ® ×»â|Ó“ß“â|×xå ÛgÏ“ßyùCú ® ×»ÒŸâxßl×¡ÒŸÙœÚ å‹âxßlÒÑ0Ü ×»Ð@ú>ØcÜ ×»ÞzÐ0Ú“Ü43’ ‚g†—Œ@v|{ƒ~Ry|{}plr>¢•¿}À û‘Á•~ v|p‘~›pl†—‚)y|‰I‚){}r˜y|‚gt‘vxwjy|{}plr#p‘qªuIr Œ…y|{}plrIw‘€®wjv|Œ@‰ {ŸŽy|‚gŒ…y|uRv|‚g†4{ƒr˜y|p§y|‰I‚Œgp‘r sAt‘u vxwjy|{ƒp‘r¢„)p‹’ ‚…€2˜ c’ ‚@sArI{}r tžwG„ˆwjy|Œ@‰ {ƒr tÜ Ï 1 Ü Ïlù˜ã ӓסۅÑ0ÒŸÜ Ï ú å'å:å:îòväà%ã&Þnß«àZ"ý¢¡-äY&]"[\¤£ò}ÛgÏ“ß“Ü“å ® òŸÜ ׻ҟߘÛlå0Ïxî î îlúv|p‘„ªu rIŒ…y|{}p‘rI†qy|p§”“‚… GŒgpl„)~›p‘rI‚gr˜y|†g¤“–4‰ {ƒŒx‰¨„GuI†œy•›‚8~Awzv—yqp‘>y|‰I‚õ4Z"[óä)ñ-Þ ÷ ß«Þvää[ß«Þ ÷ Z6ÞSÞv]6õ-ý ä ÷ ä@ñ-Þ ÷ ß«Þvä#ä–[ßøÞ ÷ åö3˜Ûgã â|Ðeç"çjíèŒgplrRsAt‘u vxwzy|{}p‘rc{Ÿ2y|‰I‚4ªuIr Œ…y|{}plrˆ†—‰Ip‘uI€ƒ’ˆ›‚C~Rv|pzŠ‹{ƒ’ ‚g’2¢ Ê š w‘Œ…y|€Ÿ žy|‰ {ƒ†Ó˜Ûgã â>ÔÜ ×AÑ¡Ú“â¥Ù|Ü Ï“Ð»Ñ0×»Ó“Ù—Ñ0ÒŸÜ ÏCÜgÔ˜ÞzÏ“Ü@áòŸâ|ß“ã â—ç{˜ÛgСâxßCÙ|Ü Ïlçù˜ã ӓסۅÑ0ÒŸÜ ÏлälлÑ0â|ÝÐxú“αϧ"\«ãSîÞn\ ä[ÞvZ"\Åßá]"ÞvZ"ý8Ûr]"Þ–^%ä[äÞvàäE]"Þµô]^\ÅöЧ3‹â|Ù|Òù˜Ù¥ò}ÛgÏ“ã{}r‹y|‚@v|~ v|‚…yxwjy|{ƒp‘rcp‘v8y|‰I‚MwzŒ@‰ {}‚gŠ“‚g„)‚gr˜y=pz¥ªu rIŒ…y|{}p‘rI†4{}†8u †—‚ ’c{}rcplu vvxwz„)‚…–®pzv|”¨p‘v4y|‰I‚{}r˜y|‚gt‘vxwjy|{}plr¢pzŒgplrRsAt‘u vxwzy|{}p‘r'†œ †œy|‚…„)†g¢çžïjìlå‹ñ=ÛgÒŸÐ0â|×»Ð0ò}ÛgÓlÑ¡â|×¡Ï åùqâx×»ÝKÛgÏjäzå0Ïxî î îlú‚9‚g†—{}tlrI{}r tc€ƒwzv|t‘‚ž†—Œ wz€ƒ‚G~ v|p‹’ u Œ…y|†Cv|‚g«‹u {Ÿv|‚g†9y|‰I‚§Œgp˜p‘~›‚…vxwzy|{}plr¦p‘}î-€¼ùCú ® ×»ÒŸâ|ߓסҟÙ0ÚžÛgÏ“ß ¦ú$ÙzÑ0ÓlÝ3lÑ0Ïlâx×|ú 1 Ü Ï“Ð0ҟлÑ0â|Ï“Ù—äzçþÔÛgÐ0â|ß 1 Ü Ï‘ù˜ã Ólç×0Û…Ñ¡ÒŸÜ ÏIúqαÏ@å:å:å'î£]"["âã$]Y ]"Þ Ûr]"Þ ÷ Ý&[Z"\Åß«]"Þ$üò3ä#à%ã&Þnßáà#Z6ý¡£ä–öw¼r‹uI„‡›‚…v)p‘’ {ŸÇP‚…v|‚gr˜ŷ ‚…šR~›‚…v—y|†g¢ ­ r¬y|‰I‚*Ì‹£M·‚ Ê ¯»Ì‹‰Awzv|‚g’ ‚M‚…Ž~›‚grA’R‚grIŒ@ Ê r tl{}rI‚…‚…v|{}rIt˜´q~Rv|p§p0‚gŒ…y¿}ÀójÁew º­ µ¬¿ƒÀ-lÁPªpzv|„ˆw‘€}{}†—„ –=wz†ÔÜ ×4Ñ¡Ú“âKÙxÜ Ï‘ù˜ã Ó“×»ÒŸÏ“ãˆÜgÔÑ¡â|ٜړϓҟÙxÛgò6Сä‘Сѡâ|ÝÐ8ÔÖ×»Ü Ý ÝÜzß“Ó“ò}Ûg×4Ù|Ü ÝMç3‹Ü Ï“â|ÏzÑ¡Ð@ú§Î±ÏRë-[ó]–àbíb\«ãeîóñ4ñ4ñêÛ]"Þ–^ä–[óä–Þvà#ä ]"Þ)å:îÌZY6Y3ý à–ß«Z"\Åßá]"ÞnâuI†—‚ ’¬ªp‘v¨v|‚g~Rv|‚g†—‚gr˜y|{}rIt#‚gr tl{}rI‚g‚@v|{ƒr t#plr˜y|pl€}p‘tl{}‚g†g¢2Ê9{}Š‹{ƒr tw‘rµIu’¬p‘r›pluIrI’ ‚ ’#€}‚ wjv|rI{}rIt†œy—vxwzy|‚gt‘{}‚g†)†—uIŒx‰¬w‘†)wz†œ r Œ@‰Rv|plr pluI†AwzŒ@”˜y—vxw‘Œx”‹{}rIt ¢®½®‰I‚*Œgp‘rIŒg‚g~Ry|†c~Rv|‚g†—‚gr˜y|‚ ’

¦¤¡ ¢ ¡£¢¤§¦¡© !¤" #!$ ¡£%¡£¢¥¤§¦¨¡©¤&¢¥¤§¦'(¡£)¤ *+¤¨¡£¢-,.%/¤¡c.dfeLgihkjmllonpeLqsrutvgwjmexryqzg{rzj|qs}~gilorzjmniebUtznp€f|‚ohƒ„cN…A†f‡‰ĴqunpmŠxjmeL‹r hk‚orzLnx‘Uq}~nwtqunimŠUjmef‹@Špg{tzjmnp’Lqjmq§nieL‚nw}ŒrzL‚¨hknpqsr-jmhkŽniturvgwej|eL‘fqNni}EKL;?A>EF436;=>LF4MEKNHPOQF43SRUTV7>'WA7:9.9.7MEKXLY:Z [\7>L]8^._/`P7:9.]£3B>bal”npeU—E‹i’ftvgwrzjmnie-ftznp€fm‚”h qunpmŠxjmeL‹k}~’feLlorzjmnpeLgimj¡r4d ˜L¢=nŸ£¤‚”Šp‚otŸ•Lqu’fLfmd£8fjmlDŒlonpeLquj|‘U‚otzq‰Šigwtzj|gw€Lm‚

£gŽLgiq! @Šigwtzj|gw€Lm‚”q–¬" #ª•x¯%$'& Éi˜m˜|Â)( •+*,$'& Éi˜|˜- .( ˜£8L‚otz‚º‚ŸgilvŒgw‹p‚”er8Špg{tzj­gw€Lm‚”q8EgŸŠª‚Pg ftzjmnwtzjmr·d½‘f‚”efnirz‚Ÿ‘½giq8 # ˜fΣgilv¥Špg{tzj|gi€Lm‚©.‹i‚”e # jmq8giququjm‹pef‚Ÿ‘yrznJgJ‘fnihžgijme'/102$¨/NÃ3 J°245&3/ Ï •%/76{•|˜m˜m˜ ( •f£8L‚otz‚¬/œÃ3 Àƒ~¬" #iˆ–‘f‚”efnirz‚”qrzL‚¤‘fnphžgwjmeŒni}Erzf‚AŠpg{tzj|gi€Lm‚¤¬" # ˜ª…ºnpefqsrutvgijme rzqrzL‚¥gwququjm‹peLhk‚oexr8¬" #34Œ®i˜#ª•U¬ F+G •LgieL‘y¬ J+K g{tz‚N‘fj¡§S‚otz‚”e r

zq”˜’LnwtNrzLjmq¥l”npexŠª‚Dtzquj|nië r4£ºn¥‹p‚oeL‚otvgw‰hk‚orzfnx‘fq€LjmeEg{tud§l”npefqsrutvgijme“ eLnŸ£8e > rzf‚A‘f’Lgix‹itvgwLŒhk‚DrzLnx‘kÈ ôwÊLgweE‘NrzL‚¤fj­‘f‘f‚”e Špg{tzj|gi€Lm‚gwtz‚[ Ê´˜d¨‚ž‘f‚”efnirz‚kr4£ºn-gi‹i‚”e rzqœ£8fnpqu‚yŠpg{tzj|gi€Lm‚”qœEg{turzjml”j¡›hk‚orzLnx‘'ÈmÉ£8L‚otz‚E^ # lŸgie2‚”j¡rzL‚otktz‚oftz‚”qu‚”e ržg§l”npe rz‚”e rkŠigwtzj|gw€Lm‚¥nityg§qsrvgwrz‚Špg{tzj|gi€Lm‚p˜0¾_?L7Mf]8Fs9.GVCvlj>å“ø4ÅO¹O=!çnpe giqsdUeflDUtznpeLni’Lq–€Lgil “ rutvgil “ jmef‹

¸4eyrzL‚P}~nim|nŸ£8jmeL‹k£º‚¥‹pjmŠª‚NgJqujmhkLm‚¥‚o¬fgwhkLm‚Pl”nieLqujmqsrzjmeL‹kni}šrzftz‚”‚rzq_T Ï o,T63oBgieL‘¨TÞƒ„qu‚”‚ ¤ ¯|Äiµx²z‰§6ˆD˜%L’fturzf‚ot8£¤‚œ‘f‚D—EeL‚œgŒqu‚orgi‹i‚”eÏ •¬6i•¬"ÃI(P€Ž‚”mnpeL‹ijmeL‹JrznNrzL‚=gi‹p‚oexrzqeT Ï oMT63oEgieE‘¬TÃni}šŠpg{tzj­gw€Lm‚”q7&”¬£8L‚otz‚‰/NÃ3 Œƒ~¬ Ï ˆQ4.&ªÉp• [ (ª•ü/NÃ3 Œƒ~¬ 6 ˆQ4.&{Ë?( •EgieL‘/œÃA Œƒ~¬ à ˆQ4.& [ ( ˜Ì ÊËÏÌËÊ×~Ø•Ù"Ú%Û+ÜÓÒÞ®ß ¿pݔ߽áªô¡äŸõ?âºÔ¡ÒÚÓ4ØÚÔãÀªÕpÓ·äzá„â‰æiÑ Ý”ß¥Ô¡ÛwäMìp豄¯kniD•P¯~Â%T¥o±„¯kniA( ˜1–jmeLgim¡d •¤£¤‚§jmexrutznx‘U’Ll”‚-rzf‚ }«npmmnŸ£8j|ef‹@gwlorzjmŠUj¡r·dY¤ ¯|Äiµx²z.-quLnŸ£8qA}~np’Ut=queLgifquLnirzq8nw}–rzL‚PqunimŠUjmef‹kftzn l”‚”quq”˜ÎÊËÎÛÚÜÜÚrwT Ï mn lŸgwmmd jmeLqsrvgwexrzj|g{rz‚”qj¡rzqŠpg{tzj­gw€Lm‚”q–£8j¡rzLni’frtz‚”‹pgwtv‘Uj|ef‹©.‹i‚”erzq > ¬ Ï 4 Éi˜dC.nŸ£T Ï qu‚oeE‘fqNj¡rzqrzf‚ŒjmeLqsrvgwexrzj|g{rzj|nieLqœni}¤tz‚ohknirz‚žgi‹i‚”erzj|gwrzjmnierznrzL‚ŒlonpeLqsrutvgwjmexr ‚”Šigim’Eg{rzjmeL‹-gw‹p‚”e rzq†T6Šigwtzj|gw€Lm‚kjmeLqsrvgiegweE‘NgÃ1oªj„˜‚p˜fÃI:põ ¢ » o ¢ Ï o » ©¦©.˜w©®M~ g f ¡ 0£¢ fhg9igkjAf @KJbKMNIEbLDFEG?§J&©W¯KAà(a)x 1x Ý 1=1x 1status=activeà(b)x 1g f ¡ 0£¢ h 0 i±x Ú 3=2x 3statusx 3Ø=activex Ù 2 x 2=3x 2status=activex 3Øx 2Ùg f ¡ 0£¢ A¦bDFEGM8~ž«Y­¨?W@"d(EGKbKeLNKMLELB>®g f ¡ 0£¢ Ÿ M~?§J&©°FAg f ¡ 0£¢ fhg9igkj3f Ÿ g f ¡ 0£¢ fhgBigkjAfh 0 i bLDFEG?§J&©³²¨A {LEGIÔ PR"SUTFP‘F6’W“„X6P[ f ¡ 0£¢ X\ f ¡ 0£¢ ]"](]J"^8G6{b"HI@KMGKbQELNI@Iz8‡F@LbFMGKd€@"dIE8GKbF{„fbK^ˆJL^8G(GFEKJ8bIE"O?§J&©WḰA E(zI{LEG¨^LdK^"^LOF{ jlµ f&· fS§ @LdIEGKbKeNFMLELB HEGKOQM8~ofagent_view(x3):x 1=1x 1status=activeÛagent_view(x2):x 1=1x 1status=activex Ú 3=2x 3status=activenogood(2,{(1, (x 1status,active)),,active))})(3,(x 3statusMG6J"^8G¨{(M({bIE8GKbo? )f ®§¸¨R¦¹:? g f ¡ 0£¢ At®§¸¨Rm¹:? g f ¡ 0£¢ fhg9igkj3f A(Aº&frF@IJnKb(HI@IJn»?[G¨^dK^(^LOF{IA fEIzI{EKM~E8GKO€M~off ¡ 0£¢ fhgBigkjAf Ÿ?§J&©¼FA {LEGKOQPR"S TFPW‘F6’“„XYP[ fg0£¢ fhg9igkjAf X\ f ¡ 0£¢ fhg9igkjAf ]"](]bK^ˆJ"^8G"GFEKJbIELO ¡f ¡ 0£¢ fhg9igkj3f³h 0 i bLDKEG gEGKOQM~ofJ"^8G6{8b(HI@KMGIbQE"NI@Iz8‡K@"bFMGKd€@"d(EGKbF{„fà(c)Ý ,1))})à(d)x 1x 1=2,x 1status=activenogood(3,{(1,(x 1x 1x3x Ú 3status=inactivex 2Ùx 2statusx ß 2=3=activejcµ?f · )f § @"dIEGKbIeLNFMLELB H?§J&©½FAkEIzI{LEG¨^dK^(^LOF{ f ®¸¨Rm¹:? g f ¡ 0£¢ fhg9ig9j3f A(Aº&fMG6JL^8G6{(M({8bIEGKbo?fEGKO€M8~ofrF@IJnKb(HI@IJn»?[G¨^dK^(^LOF{IAE8GKO€JDFEIJn¨e"@"d(EGKbKeLNKMLELB>f?O6AŠÏHK^IJLE"O‡KHIEcrF@KJmnKb(HI@KJmnˆ?[GF^LdK^(^LOK{KA fx 3ØÞx2agent_view(x3):x 1=2x 1status=activeagent_view(x2):x Ý 1=2x Ý 1 status=activex 3status=inactive¡ $ M~@"dIE8GKbF{¿? … À{"^(z8‡KbKM"^8GtA frKHK^L@"OFJL@K{8bˆbK^-^LbLDKE"Ĥ×~Ø-ÙÚ%ÛLܾá%Þãâ Ô¡äzã£Ò:ÞŸÑ Ó·Üªä8Ò4ÞŸôëiԡѪå7áªØ·ÞwÛzäzÒ4ÒGF^LdK^(^LOK{¾bDFEGbIE"HÁtMGF@"b(Ê @IzLdK^LHKMbLDLÁfflŸgw,T”Ä DÂL±B÷OnŸ¯ÚL]:˜fþºnwrz¥gi‹i‚”e rAŠigwtzj|gi€f|‚oq8gwtz‚¥gwlorzjmŠpg{rz‚Ÿ‘6•jmežrzL‚”j¡tAmnr.gÃj„˜‚pŨrzL‚Pqsrvg{rz‚¥ni}–¬6PgweE‘y¬"Ã=jmq8lvEgief‹p‚Ÿ‘žrznT¥o±„¯kniD˜C=nŸ£bgi‹i‚”equ‚oeE‘fq‰j¡rzqºŠigwtzj|gi€f|‚

Q¥zÃiÂŽ®w•ªgw|UŠigwtzj|gi€f|‚oq–¬h$üÆefg9i¦gSgwtz‚AgwlorzjmŠª‚AgieL‘œjmefqsrvgie rzj|gwrz‚Ÿ‘NjmeŒg£Bfg9igkjAfœ T¥o±„¯kni.jmq¤g¥mn lŸgwŽl”npefqsrutvgijme r¤ni}šgi‹i‚”e rAg qunpm’frzjmnieB•xqujmeLl”‚8¬rzj|gwrz‚”‘6˜üL’UturzL‚otŸ•E¬ lŸgwe eLnirgieL‘§gwm‰gwlorzjmŠª‚JŠigwtzj|gw€Lm‚”q¥g{tz‚ŒjmeLqsrvgie€Ž‚‘U‚ŸgilDrzj|Šigwrz‚”‘6•:qujmeLl”‚ž¬"Bfg9igkjAf œ T¥o±„¯kniLni|‘fq”˜.¼µ‘x¯~²s®i•rzL‚yhkjmef›Y$ª/œÃ3 ¢ ¤©Ÿ˜¤¤f‚”qu‚ÂŽÃzĪßß®w° gwtz‚-ef‚”‚Ÿ‘f‚”‘¾rzngŸŠªnij|‘/qu’L€fqu‚Ÿ¦ ’L‚”e rYd§rznirvgiºnitv‘f‚Dtzj|ef‹f•B£8LjmlDrvg “ ‚”qœgp‘UŠpgwe rvgi‹p‚žnw}ArzL‚žgilDrz’Egi’fqu‚žgiegim‹pnwtzj¡rzLh gimqun@Ž‚Dtu}~nitzhkq-‹wtvgifUtznp€f|‚ohqsrutz’Llorz’Utz‚gweE‘¹rzLjmq“ rutvgwl “ jmeL‹Uâ=nŸ£¤‚oŠª‚otŸ•8jmeÁUtvgilorzjml”‚Špg{tzj|gi€Lm‚nitv‘f‚Dtzj|ef‹€Lgiqu‚Ÿ‘Q€Egwlðdyj|e rz‚otzef‚or8rz‚”lvLeLnimnp‹pjm‚”q.€Žn npqsrzq¤f‚¥jmexrz‚o‹itvgwrzjmnie-ni}:€L’fqujmeL‚”ququ‚”q

Ý”ô{ÒÚÓsÝoÓ·äzÒŽÞ”ÖªáªÔ¡ÒÚÓ4ØÚÔãÀªÕpÓ·äzá.ÒÚæpÒÚÓ4äzߥÒDüm¥¤§¦©Ï[8I ¤„!Ls¥ W*mç(ÿpçãîŸõíÿþpï”îpç%îvðýŸîpüԡѪå:åŸô¡ÞÀW§!p :¥"§©86üW W "§š¤U8t"[8 çUë{ÞŸô¡Õªß¥äeîyÿpç òªç)á Ý”åŸäzÒ¥üèŽü„â¤Ý”ØÚؾݔѪá+Ù¾üèSü¾ø–ԡطߥԡÑpåŸÜ ݔߌü â‰Ñ+âÓÚÓ4ØÚÔãÀªÕpÓ·äué‹ì3á Ý”ÛzäëÀ Ý”Û4àD÷Úժ߽áªÔ¡Ñªåªç6ô¡ävÝ”ØÚѪԡѪå½Ý”Ѫá ÛvÕiÓ4Ò·äzÓNápävÛzÞŸß½áxÞŸÒ4ÔÓ·Ô¡ÞŸÑLü / &©y/íý+ïâ

User Interface Requirements forKnowledge Acquisition and ModelingGerhard Fleischanderl 1Abstract. User interfaces for knowledge acquisition are mainlytargeted at expert users or knowledgeable intermittent users. Thereforethe design of such a user interfaces has to find the balancebetween ease-of-use and handling-efficiency. Out of a set of generalrules for interface design, enabling shortcuts, informativefeedback and error prevention seem to be most important forknowledge acquisition tasks.1 INTRODUCTIONWithin this paper, knowledge acquisition means knowledge basemodeling, i.e. editing and maintaining knowledge bases.The user interfaces for knowledge acquisition must fulfil particularrequirements that are different from “normal” user interfaces.Knowledge acquisition is similar to programming and is often doneby computer and software specialists. Furthermore, domain expertsalso do knowledge acquisition tasks.This short paper contrasts the general ergonomic principles for userinterfaces [1] with the requirements for knowledge acquisition.Three real-world user interfaces for knowledge acquisition forconfigurators are compared to the general principles.2 EXAMPLES FROM REAL-WORLDPROJECTSThis paper draws on experience from several configurators [2] andknowledge-acquisition interfaces that are in production use inSiemens sales and engineering departments. From these real-worldapplications we pick two examples to illustrate the requirementsand discuss the experiences from usage in the field. The two examplescover a relevant range of user interfaces. Furthermore, wediscuss properties of the visual modeler described in [3].KBE - Knowledge Base Editor for configurableproductsKBE is used to model the configuration knowledge about productsthat are sold with private branch exchanges (e.g. phone devices,specialized software packages). The knowledge bases edited withKBE are then compiled into code for different configurators.In a structured tree view, the user can find and access the configurationobjects of he knowledge base. The properties of an objectcan be manipulated in a detailed input form. In particular, KBEsupports the editing of expressions in an efficient manner.KBE was specifically designed to make the editing and maintenanceof configuration knowledge bases easier and faster, and toimprove the quality of the knowledge bases. The features of KBEinclude checks for unused attributes, a syntax-driven formulaeditor, undo-redo facility, and an update mechanism for importingdata from external product databases.Engineers from the author's team developed KBE.CBC - Class browser with constraintsFor editing the knowledge base for a configurator for telecomswitches, we used the class browser of the underlying Smalltalkenvironment and added a facility for defining constraints.The class browser has selection windows for accessing classes,their attributes and methods. In a separate input window the propertiesof a class can be manipulated.CBC offers advantages to programmers who are familiar withdevelopment environments for object-oriented programming languages.Furthermore, we introduced tables to allow non-expertusers to do routine maintenance like modifications to part numbers.CBC was developed within a larger project led by the author.Visual modelerIn [3], Heiderscheidt and Skovgaard describe their approach for thevisualization of configurations and a visual modeler. Productmodel rules and visual rules are handled separately from oneanother. In that environment the user can see both the configurationmodel and visual model. Checks between the models assist the userwhen he/she creates the rules for visualization.3 USAGE PROFILESWe distinguish three generic groups in a user community [1].Novice or first-time usersThis user group is rare in knowledge acquisition tasks. For knowledgeacquisition, users really should have some training or relevantexperience. Untrained users may do simple tasks, like modificationsto part numbers.1 Siemens AG Österreich, Program and Systems Engineering,Erdberger Laende 26, A-1030 Vienna, Austria,email: gerhard.fleischanderl@siemens.at41

Knowledgeable intermittent usersAs knowledge-based systems are used for more applications, wewill find more users with some skills in using a knowledge-acquisitionuser interface. They will understand some of the concepts,but will need support for finding their way around the features ofthe user interface. For them the user interface ought to be verbose.Expert frequent usersThe ‘power’ users want to do their tasks quickly and demand anefficient user interface.ComparisonFor knowledge acquisition, expert frequent users were the maintarget group. Yet, intermittent users will become more and moreimportant as users.The race continues between improving the user interfaces forknowledge acquisition and enlarging the capabilities of the underlyingknowledge-based systems. More features mean more variety.Therefore the frequent users, too, become intermittent users whenthey come across a feature they rarely use.KBE was designed for expert users as well as intermittent users.Therefore, its features are a compromise between the requirementsof the two user groups.CBC is targeting the expert users. It is hard to learn and hard to usefor non-experts.The visual modeler described in [3] provides an integrated environmentfor modeling both product rules and visualization rules.This helps the intermittent users to work more efficiently.4 THE EIGHT GOLDEN RULES OFINTERFACE DESIGNShneiderman [1] presents eight rules that are the underlying principlesof good interface design. In this section we describe theeight rules and compare them each to properties of the interfacesKBE and CBC. Finally, we subjectively rate each rule whether it isimportant for knowledge acquisition.Rule 1: Strive for consistencyFor instance, consistent sequences of actions should be required insimilar situations. Yet, there are many forms of consistency, whichoften prevents overall consistency.• KBE uses a tree view and input forms for letting the user edita knowledge base. The input forms contain sub-windows forclustering data. This layout is used for all windows.• For editing constraint code, CBC allows input via forms ordirect source-code input. Input forms for tables are againdifferent from the input forms for constraints. The mixturebetween forms and pure source-code is sometimes helpful,sometimes a bit disturbing. Using forms (input fields) on topof a standard class browser creates inconsistency for the user.• In [3] a visual modeler is described. There the product modelrules and visual rules are separated, which reduces complexityfor maintenance. Knowledge acquisition for product modeland visual rules, respectively, are consistent each amongthemselves.Relevance of this rule to knowledge acquisition: Medium. Lack ofconsistency makes the handling more tedious, but users will partlyget accustomed to that.Rule 2: Enable frequent users to use shortcutsFrequent users often appreciate abbreviations and macro facilities.• KBE allows the user to define abbreviations (macros) that canbe used in expressions.• CBC does not support shortcuts other than those found in thestandard class browser.Relevance of this rule to knowledge acquisition: High. Speed isimportant, especially if the expert users can envisage ways foraccelerating their work.Rule 3: Offer informative feedbackFor every user action, there should be system feedback. The visualpresentation (graphical display) offers better feedback than textbasedinterfaces.• KBE checks whether parameter names that are not definedanywhere are used in rules or formulas. This may happen inparticular when an existing parameter is removed, but wasused within an expression.• CBC checks the syntax and other properties of the underlyingprogramming language. This is done after having completedan input sequence.Relevance of this rule to knowledge acquisition: High. Poor feedbackannoys and hampers every user every time.Rule 4: Design dialogs to yield closureThe completion of a group of actions should be highlighted to theuser.• KBE does not use explicit closure of a series of actions.Explicit closure would make every action longer, thus annoyingthe experienced users. There is an automatic “to do list”,namely the flags for errors (e.g. undefined parameters). Theuser knows that every error flag has to be dealt with and caneasily find out whether this job is completed.• CBC only uses features of the standard class browser.Relevance of this rule to knowledge acquisition: Medium. Userscan compensate for missing closure.Rule 5: Offer error prevention and simpleerror handlingAs much as possible, design the system such that users cannotmake a serious error. If users make an error, the system shoulddetect the error and offer constructive instructions for recovery.• KBE has a syntax-driven formula editor that allows onlyformulas that have correct syntax. Furthermore, parametersmust have been declared before using them in formulas.• CBC only uses features of the standard class browser.• In [3] the product model and the visual model are separated.Yet, there are update mechanisms and checks in place to alertthe user when changes were done in any one model.42

Relevance of this rule to knowledge acquisition: High. Preventingmistakes in the first place is an excellent way to improve efficiencyand satisfaction.Rule 6: Permit easy reversal of actions• KBE allows chronological undo and redo across multiplesteps of actions.• CBC uses the features of the standard class browser, whichincludes undo and redo of the last action.Relevance of this rule to knowledge acquisition: Low (but desirable).Often a user interface offers features for 'manual reversal' ofactions, e.g. insert and delete.Rule 7: Support internal locus of controlExperienced users strongly desire the sense that they are in chargeof the system and that the system responds to their actions.• KBE guides the user and does checks, but does not forcehim/her into particular sequences of actions. At the end,source code for different configurators is generated. The userssee the automatic generation as a big advantage and not asloss of control.• When working with CBC, the user has to be in charge (to putit in positive words). In this case, this is only good for veryexperienced users who may nevertheless prefer working in aplain text file. So CBC looks like a compromise that does notreally please anybody.Relevance of this rule to knowledge acquisition: Low.Rule 8: Reduce short-term memory loadThe user interface should relieve the user from memorizing previousdata to carry out an action.• In KBE, input fields in forms and sub-windows are clusteredaccording to whether they belong together when specifyingthe contents of a knowledge base. With navigation betweenparts of the tree view and sub-windows, KBE supports thesearch for information outside the current input focus.• CBC does not support the search for distributed informationvery well. This is more easily achieved by editing the knowledgebase as one (large) text file.• In [3] the user can see both the configuration model and thevisual model. This enables easy access to the informationneeded for creating the visualization rules.Relevance of this rule to knowledge acquisition: Medium (but hardto achieve for complex modifications). Being able to carry out atask without switching between windows is desirable. Yet, the userinterface should not get overloaded with information.• CBC: In retrospect, maintenance of the knowledge base wasdone infrequently and relied heavily on reusing code andmodifying it to new requirements. The standard class browserlacks the facilities to easily find all the occurrences of stringsand sub-strings. It offers too much structure and too littleflexibility for finding and reusing ‘similar’ code.As it turned out, the knowledge base most of the time wasmaintained by editing the plain text file and loading the fileinto the configurator. Having the syntax only checked whenloading the text file is only a minor drawback for expert users.Yet, non-expert users can only do easy tasks with CBC.• The visual modeler and integrated environment described in[3] addresses very well some principles for interface design.When designing a user interface for knowledge acquisition, thedesigners should find out who the users would be. In general, thedesigners then ought to favor the rules no. 2 (enable shortcuts),no. 3 (give informative feedback) and no. 5 (prevent errors).Beyond the general ergonomic principles discussed in this paper,specific requirements and guidelines for designing knowledge basemodeling tools can be established. This has to take into account theenvironment and the user groups of the tool. Usability tests can bedone to find out the user interface design principles that are relevantto the task.REFERENCES[1] B. Shneiderman, Designing the User Interface (Strategies forEffective Human-Computer Interaction), Addison Wesley Longman,3 rd edn, 1998.[2] G. Fleischanderl, G. E. Friedrich, A. Haselböck, H. Schreiner, and M.Stumptner, 'Configuring Large Systems Using Generative ConstraintSatisfaction', IEEE Intelligent Systems & their applications, 13:4,pp.59-68, July/Aug. 1998.[3] D. Heiderscheidt and H.J. Skovgaard, 'Visualization ofConfigurations: Simplifying Configuration User Interfaces', AAAITechnical Report WS-99-05, pp.114-118, Papers from the AAAIWorkshop on Configuration, Orlando, Fla., July 1999.5 CONCLUSIONThe principles for good interface design also apply to user interfacesfor knowledge acquisition. Yet, the requirements of knowledgeacquisition interfaces emphasize the needs of frequent users.• KBE: The effort of designing KBE for usability and efficiencypaid off. The experiences of both expert and intermittent usersare very favorable towards KBE.43

Configuration of a machining operationLaurent Geneste 1 , Magali Ruet 1 , Thibaud Monteiro 2Abstract. The problem of configuring a machiningoperation is complex (many parameters and manyinteractions between parameters) and is generallyachieved thanks to expert heuristic knowledge such assequential choice of the parameters according to localtechnical constraints or reuse and adaptation of analready defined solution. In order to support theconfiguration of a machining operation, we describefirst the nature of the data involved and then thedifferent solving processes that can be used.12search. The complexity of the problem leads expertswho carry out machining process configuration tofollow two different heuristic methods :• sequential selection of the parameters andtherefore progressive building of asolution without taking into account thewhole set of technical constraints,• reuse and adaptation of an already definedsolution.PartToolsKeywords. Machining operation configuration,C.S.P., C.B.R.1 INTRODUCTIONIn recent research work, the need of interactivedecision support system in the field of productconfiguration has been clearly emphasised for examplein [1]. However, the problem of machining operationconfiguration is scarcely addressed in the literature.This paper aims at presenting the specificity of thisconfiguration problem and of the solving process.The problem of configuration of a machiningoperation, illustrated by figure 1, may be described asfollows: in order to ensure an adequate machining of apart, several parameters for the machining operationhave to be defined. These parameters are for instancethe kind of operation that will be performed (e.g.milling, drilling…), the machine on which theoperation is to be performed, the tools that will beused, the feed rate and so on.The choice of the parameters must be achieved inaccordance with technical constraints (some tools donot adapt on some machines, the energy necessary forthe operation should be available on the machine…).Moreover, optimisation criteria are often defined inorder to select a solution among the set ofconfigurations that respect the technical constraints.This problem is very complex essentially because ofthe combinatorial characteristics of the domain of1 Equipe PA – LGP - ENIT - Avenue Azereix, 65000Tarbes, France, email: laurent@enit.fr, ruet@enit.fr2 LAG - ENSIEG - INPG - Rue de la Houille Blanche - B.P.46, 38402 Saint Martin d'Hères Cedex – email:Thibaud.Monteiro@inpg.frMachineConfiguration of themachining operationFigure 1. Configuring a machining operationSeveral decision support tools are provided, especiallyby tool manufacturers. These tools enable to selecteasily some of the parameters according to aspecification of the context. For example given thecharacteristics of a tool and wear and of the part, sucha system may compute a relevant value for the feedrate and the depth of cut in a turning operation.However, once again, these tools are used in a specificstep of the configuration process, when the major partof parameters is already defined.As a conclusion, we observe that the problem ofmachining process configuration remains most of thetime based on empirical data layout andmethodologies. This leads us to propose an explicitrepresentation of the domain knowledge (knowledgelayout, decision variables and technical constraints)and a set of manipulation techniques that support theconfiguration process in order to provide the user withan interactive decision support system that allow himto develop his own strategies for the problem solving.44

2 CONFIGURATION DATA MODELLINGIn order to make a standard modelling of the domainknowledge, we selected the object oriented modellinglanguage U.M.L. (Unified Modelling Language) [2].We use the U.M.L. class diagram and object diagramin order to represent the domain data. In order toexplicit the technical constraints, we added to thebasic U.M.L. graphic notation, a specific notation forthe concept of constraint as illustrated by figure 2. Wecan observe that the classical concept of association isa specific case of constraint in which the involvedattributes are the references of the associated objects.Class BAttributes:B.b1B.b2Operations:B.mb1a2b1Attributes:AB.ab1AB.ab2Opérations :AB.mab1Constraint ABAssociationClass AAttributes:A.a1A.a2Operations:A.ma1A.ma2Figure 2. Notation of a constraint between twoattributesAccording to [3] and to several experts of themanufacturing domain, we identified a set of variables(attributes of the classes of the U.M.L. class diagram)and of constraints that act upon the configuration of amachining operation [4].We identified more than 30 variables that are usefulfor the configuration of a machining operation. Someof this variables are defined over discrete domains (forinstance X4: tool holding device, X7: type of insert orX19: tool material) and the others are defined overcontinuous domains (for instance X8: precision ,X14: cutting speed or X22: surface roughness of part).We also identified 32 technical constraints that shouldbe taken into account in order to make an adequateconfiguration of the machining operation.We can observe that some constraints are:• binary such as:• C1 (X5,X7) : Adaptation constraintbetween the kind of tool shank and thetype of insert. Cutting tool manufacturersgenerally provide with a list of validcouples (tool shank, wear))• of arity more than 2 such as:• C11(X7,X10,X11,X14,X16,X20) : Thechip breaker diagram: for a goodmachining , it is important that the chip isfragmented. The fragmentation of the chipfor a given cutting speed Vc and feed ratef. We obtain experimentally a workingzone where the couple (Vc,f) leads to abroken chip.).Some constraints are on variable defined :• over discrete domains only as for instance:• C2(X6,X7) and C3(X5,X6) : There existfour normalised clamping systems. Thechoice of a clamping system is linked tothe choice of the insert (C2) and of thetool shank (C3),• over continuous domains only as for instance:• C23(X11,X24,X26) : The effective lengthof cut L is function of the working majorcut edge angle κr and of the depth of cut.• C31(X9,X24,X31) : The feed force Ff isfunction of the cut force Fv and thedirection of the major cutting edge angleκr.• over both discrete and continuous domains asfor instance:• C8(X6,X9) : The cut force must betolerable for the cutting tool. Over a givenvalue of cutting force the tool begins tobend and the result of the machiningoperation may not be satisfying.• C17(X10,X21,X22) : The surfaceroughness of the part is function of themachining conditions, of the corner radiusRε and of the feed rate f of the tool.Some constraints are described• in extension (table) such as:• C9(X1,X5) : In order to machine aprofile, only some tool shank areacceptable. Indeed, it is necessary thatthe shape of the tool is acceptable forthe profile to machine. Manufacturersprovide with a list of couples (toolshank, profile).• in intention (predicate) such as:• C31(X9,X24,X31) : The feed force Ffis function of the cut force Fv and thedirection of the major cutting edgeangle κr.Ff = Fv .( 0,15 − 0,1. cos χ r)45

3 CONFIGURATION PROCESSAs exposed in part 1, two major approaches are usedwhen configuring a machining operation.3.1 Configuration as a C.S.P.The first approach is to build incrementally a solutionby restricting the domain of the variables according toa set of technical constraints and try to use the expertknowledge for guiding the search first to a solutionand hopefully to a good one. A substantial decisionsupport would be to guide the search of the solution byinteractively applying a set of constraints chosen bythe machining operation designer. In this case, theproblem of configuration can be compared to aConstraint Satisfaction Problem and all the techniquesdeveloped in this field can be applied. We use theDnGAC-4 [5] algorithm for a dynamic (one canadd/remove constraints dynamically) propagation ofconstraints of arity n defined on discrete domains only.For constraints of arity n defined on continuousdomains only, recent approaches [6] provide a relevantframework for a generic constraint propagation basedon a decomposition of the constraints into quadtrees(for binary constraints) or more generally 2 k trees (forconstraints of arity superior to 2).A recent work [7] has emphasised the need ofinteractive configuration tools taking into account bothdiscrete and continuous constraints for example in thefield of Computer Aided Design. This works pointsout and explains the relevance of a constraint basedapproach for configuration compared to the rule basedapproach. Two kinds of constraints are depicted:- activity constraints [8] which enable anincremental introduction of the variables and of theconstraints,- compatibility constraints which are theconstraints of the domain.However, many constraints that are to be manipulatedhave both discrete and continuous variables. In thiscase, the preceding techniques can not be applieddirectly and we are looking for a way to manage thiskind of constraints. Another interesting point is thatwithin the object oriented modelling some implicitconstraints are present and could be used to acceleratethe solving process. For example, when the designerdefines a class, he defines an implicit constraintbetween the attributes of the class, and this constraintcould be propagated.3.2. Configuration as a C.B.R.The second approach is to find a solution that hasalready been validated on a similar case and to adapt itfor solving the new problem. In order to support thisprocess, we provide the operation designer with afuzzy C.B.R. (Case Based Reasoning) mechanism [9],[10]. The basic algorithm is recursive and propagatesthrough the object structure. The user can weight theattributes in order to describe their expected influenceon the result of the comparison. The result of thesearch is a necessity and a possibility degree thatrepresent to which point a case stored in the objectstructure is close to the case to be solved.Again, the underlying object structure is used in orderto carry out a rough filtering of the potential objects ofinterest in the object structure and then to retrievespecific relevant cases.3.2.1. Rough filteringIn order to enable a fast selection of the objectspotentially interesting in the similar case search, wepropose to exploit the object modelling as an indexingbase. The filtering process is therefore achieved bycomparing the characteristics of the class of thereference object (o belonging to class O) and eachclass of the class diagram of the domain (class O’).From the similarity between classes O and O’, we candecide whether or not to inspect in more detail theobjects belonging to class O’. We use the followingnotation to describe the used algorithm:name(a) : name of the attribute aclass(a): class of the attribute avalue(a): value of the attribute aw a : subjective weight of attribute aRough filtering algorithm: computing of S(O,O')InitialisationS=0For each attribute a belonging to class OS = S + w a if name(a) belongs to class O’For each aggregation C belonging to class O (O iscomposed of C)NormalisationS = S + w C .S(C,C')S∑= S / w i,i ∈O46

Let us notice that the weights attributed by the user tothe attributes are used in order to describe thereference case are used by the rough filteringalgorithm. This enables, when required, to findsimilarities between very different classes which havein common attributes important for the seach of theuser.3.2.2 Case retrievalOnce the set of candidate classes is selected, we canachieve the search of cases similar to the referencecase among the objets derived from these classes. Thefollowing algorithm computes the necessity ofsimilarity of objects o and o’. A similar algorithmenable to compute the corresponding possibilitydegree.Case retrieval algorithm: computing of N(o,o')InitialisationN = 1For each aggregation contained in object o (os iscomposed of c, where c is an instance of class C),three cases are possible:Case 1 : o' is composed of c', where name(c') belongsto class CN = min(max(1-w C , N(c,c')),N)Case 2 : o' is composed of an object which namebelongs to class C but not instancedN = min(1-w C , N)Case 3 : o' is not composed of an object which namebelongs to class CN = min(1-w C , N)For each elementary attribute a belonging to object o,three cases are possible:Case 1 : if the corresponding attribute a' exists inobject o' and has a valueN = min(max(1-w a , N a (a,a')),N)Case 2 : if the corresponding attribute a' exists inobject o' but has no valueN = min(1-w a ,N)Case 3 : if the corresponding attribute does not exist ino'N = min(1-w a , N)3.3 Combining C.S.P. and C.B.R.In fact, we think that both approaches may becomplementary and could be used together to supportthe configuration process.First, the constraint propagation techniques mayenable to restrict rapidly the domain of search of thecase based reasoning algorithm. Combined to therough filtering algorithm, it can make the search easierby restricting the domain of search according to thetechnical constraints and to the preferences of the user.Another way to combine both techniques is to used theconstraint propagation when the user wants to adapt anexisting solution in order to solve a new problem. Wecan whether propose to the user a neighbourhood ofthe retrieved case that respect the constraints or let theuser define the adaptation by checking the constraintsatisfaction at each step.4 IMPLEMENTATIONWe propose an integrated framework called KASKOO(Knowledge Acquisition System for Object OrientedKnowledge)for an interactive decision support systemgenerator based on an object oriented knowledgerepresentation and acquisition module and amethodology of knowledge acquisition. The acquiredknowledge will then be used thanks to various andgeneric manipulation techniques, such as constraintsproblem solving and / or case based reasoning.When a large amount of information is to be used by adecision support system, in order to ensure severaldesirable properties such as maintainability, reliabilityand so on, the corresponding knowledge should bestructured. Moreover, a knowledge acquisitionmethodology must be available in order to help theuser to organise his knowledge in a relevant structure.This section describes such a methodology and thecorresponding tools provided by the KASKOOenvironment.The methodology for knowledge acquisition inKASKOO may be divided into several major steps:4.1 Specification of the knowledge structure.In KASKOO, in accordance with the standardconcepts of classes and objects, two levels ofrepresentation are defined: the class level and theobject level. These levels are successively developedin paragraphs 3.2 and 3.3.47

4.2 Implementation of the class structureThe class level enables to implement the classstructure. Classical object oriented programminglanguages, such as C++, do not provide an easyevolution of the knowledge structure. For example,when an attribute has top be added in a class ofobjects, the code of the class must be updated as wellas the user interface and the database model (ifneeded) and the code must be recompiled. Theseoperation often require specific skills in programmingthat the user of a decision support system in the fieldof manufacturing does generally not master.Moreover, in order to build a knowledge based systemwith such an environment, specific developments forthe graphical user interface and to ensure objectpersistence are required. That is why we propose adynamic object oriented knowledge acquisition systemwith the following properties:• Basic object oriented concepts: attributes andmethods, inheritance, association, aggregation,• Constraints between class attributes,• Dynamic structure of the classes: the acquisitionsystem enables a dynamic implementation of theclasses and objects. In KASKOO, all features maybe Created, Modified or Deleted as well in themodel as in the instances.• Dynamic structure objects. The acquisition systemenables a dynamic implementation of the objects.In KASKOO, all features may be Created,Modified or Deleted as well in the class model asin the object model.The automatic generation of GUI and persistenceprovides the user with a standard interfacerepresentation and enables him to focus on the centralproblem of knowledge modelling without beendisturbed by the computer technique.5 CONCLUSIONIn this paper we describe the problem of configuring amachining operation. This problem leads first to theneed of domain representation and to do so, wepropose to enrich an existing object orientedmodelling language (U.M.L.) with an explicitdescription of the notion of constraint. Then, wedefine two different ways to use the knowledge inorder to carry out the configuration process. The firstway is to use constraint propagation techniques inorder to restrict the domain of search of a validconfiguration. The second way is to use previouslydefined solution and to adapt them to a new situation.We propose some ideas on the way to combine bothapproaches.4.3 Implementation of the objects of the domainThe object level enables to instanciate the classstructure with the appropriate objects. In order tofacilitate the knowledge capitalisation, severalacquisition mechanisms have been provided.• Automatic generation of a Graphical UserInterface (GUI). The Graphical User Interface forknowledge acquisition in KASKOO isautomatically derived from the class structure.This enables to use a homogeneous presentation ofthe interface that facilitates the userunderstanding. Moreover, changes in the shape ofthe GUI are factorised and dynamically applied tothe whole GUI.• Automatic generation of persistent database forobjects. In order to store the knowledge, a genericpersistence mechanism is used. This feature reliesupon an object oriented database. The drivers thatconnect transient (non persistent) objects and theirpersistent image are generated automatically byKASKOO.486 REFERENCES[1] Brown D.C., Some Thoughts on ConfigurationProcesses, AAAI 1996 Fall Symposium Workshop:Configuration, MIT, Cambridge, Massachusetts, USA,November 9-11, 1996.[2] Fowler M., Scott K., Booch G., Uml Distilled:Applying the Standard Object Modeling Language,Addison-Wesley Pub Co, 1997.[3] Boothroyd G., Knight W.A., Fundamentals ofmachining and machine tools, Marcel Dekker Inc.,1989.[4] Monteiro T, Perpen J.L., Geneste L. Configuring amachining operation as a constraint satisfactionproblem. In nternational Conference onComputational Intelligence for Modelling Control andAutomation, Vienne : Austria, 1999.[5] Bessière C., Arc-consistency in dynamic constraintsatisfaction problems. Proceedings of the 10 th AAAI,California, p. 221-226, 1991.[6] Sam D., Constraint consistency techniques forcontinuous domains, PhD Thesis, EPFL Lausanne,1995.[7] Gelle E., Weigel R., Interactive Configurationusing Constraint Satisfaction Techniques, SecondInternational Conference on Practical Application of

Constraint Technology, PACT-96, pp57-72, London,April 1996.[8] Mittal S., Falkenhainer B., Dynamic ConstraintSatisfaction Problems, Proceedings of AAI-90, pp25-32, 1990.[9] Kolodner J., Case Based Reasoning, MorganKaufman Publishers Inc., 1993.[10] Aamodt A., Plaza E., Case-Based Reasoning:Foundational Issues, Methodological Variations, andSystem Approaches. Artificial IntelligenceCommunications, IOS Press, vol. 7 : 1, pp. 39-59.1994.49

Description and Configuration of Complex TechnicalProducts in a Virtual StoreDiego Magro and Pietro TorassoDipartimento di Informatica, Università di TorinoCorso Svizzera 185; 10149 Torino; Italymagro, torasso¡ @di.unito.itAbstract. The paper describes a representation formalism for thedescription of products and the associated reasoning mechanisms forthe configuration of complex products in a virtual store where a customer(potentially non expert of the domain) has to be supported inthe task of selecting and assembling a product. We ¢¤£¦¥ present , aconceptual formalism where both taxonomical and partonomical relationshipscan be modeled and complex constraints among componentsand sub-components can be described by means of a constraintlanguage.Two inference mechanisms have been defined: hypothesis formulationfor hypothesizing the set of complex products a set of componentscan be part of. Hypothesis validation verifies whether it ispossible to build an instance of a complex product which includesall the components chosen by the customer by taking into accountthe taxonomy, the partonomy, the constraints among components aswell as the user requirements. This mechanism is also able to pointout which components have to be added in order to properly configuringthe product.The paper discusses how the combination of hypothesis formulationand hypothesis validation can be used for supporting a customerin selecting and configuring a product. The domain of Personal Computersand their related components is used as a test bed of the system.1 IntroductionIn recent years the diffusion of on-line services and in particularthe development of business to consumer e-commerce has shownthe central role of recommending ([10]). In fact, more and more researchershave recognized the need to support the client in selectingthe goods (or services) sold in a virtual store. Most recommendingsystems (see for example [9]) focus their attention on mechanismsable to relate preferences (directly expressed by the user or inferredby the system) with the characteristics of the products. Such an approachimplicitly assumes that the task of recommending can be reducedto a form of classification (where the requirements of the userare matched with the characteristics of the products) followed by astep of ranking the products according to some measure of the degreeof match (see for example [1]). This approach works as long asthe products can be viewed as entities without a structure in terms ofsub-parts and therefore entities can be described by means of a vectorof pairs §©¨¨© (for example, movies, restaurants, bookscan, in many cases, be described in such a way). However, there aredomains where the task of recommending involves more complexreasoning mechanisms since there is no single product that can satisfythe requirements of the client. The solution cannot be selectedamong a set of predefined entities, but has to be synthesized by assemblingand configuring a set of products in order to form a complexproduct able to meet the user requirements 1 . In this way the task ofrecommending can be described as a task of configuration.In such kinds of applications, the language used for describingthe products should be rich enough to capture the complex set ofrelations existing among the different products and the constraintswhich specify what kind of products can be assembled starting fromsub-components.In the present paper we focus our attention on the descriptionand configuration of products in the framework of web stores ableto customize both the recommendation and the interaction to theneeds of a client. The expertise gained in SeTA, a multi-agent architecturefor personalized interaction with the client of a virtualstore (see http://www.di.unito.it/ seta for a in-depth description ofthe project), is relevant for the present project since in SeTA a numberof problems related to the interaction with different kinds of usershave been solved. However, in SeTA the client can navigate the virtualcatalogue and the system is able to suggest specific products thatbest match his/her needs and preferences (partly provided directlyby the client and partly inferred by the system). In such an activitythere is no need of combining together sub-components in order toprovide the functionality required by the user since there are specificproducts satisfying more than one functionality.On the contrary, in the present project we aim at providing the userwith suggestions and recommendations in domains where:- products can be assembled and configured starting from components- the functions and the performances of a product can be extended orupgraded by adding or substituting one or more components.The attention to the needs of different kinds of clients (some ofthem possibly naive of the domain) has an impact not only on thestyle of interaction (not discussed in the present paper) but also onthe representation issue. In fact, the need of making understandableto the user the selection and configuration task requires a descriptionof the products which is able to characterize them in terms offeatures as well as to express complex relations among products andcomponents. As a test bed of our approach the domain of personalcomputers has been selected since this is a typical mass product marketwhere configuration is relevant and the need of supporting differ-This does not only occur in technical domains, but also in financial applicationssuch as portfolio management.50

+ent kinds of clients with different degrees of expertise and differentrequirements is of primary importance.The framework that we present is currently implemented in a prototypethat is being developed in Java.In the present paper, after introducing the basic domain concepts(section 2), we focus our attention on the representation mechanismsadopted for describing the complex products as well as the componentsand sub-components (section 3), whilst in subsection 3.1 wediscuss the constraints language. In section 4 we sketch the kind ofservices the system has to provide and we briefly present the reasoningmechanisms that, in combination, are able to provide the requiredservices.2 Basic Domain ConceptsBefore describing the main features of the representation language,it is worth pointing out the basic choices in modeling the domain.The most relevant distinction concerns atomic products vs. complexproducts and such a distinction is based on the need for a given productto take into consideration its parts and sub-components. In particular,atomic products are described via features which synthesizethe relevant characteristics of the product without referring to theirparts while complex products include in their description referenceto their parts and to the relations among the parts where each part (orcomponent) can be an atomic product or a complex one.Various kinds of part-whole relations have been studied in [7, 12].Following the terminology of [7], we are concerned with a partwholerelation of type complex-component. It is worth noting thatthe atomicity of a product is strongly task dependent: for examplea keyboard in our test bed domain is modeled as an atomic productbecause in a virtual store selling personal computers there is littlebenefit in describing that a keyboard is made up, among others, ofkeys and that the keys are arranged in a given order on the keyboardand so on. It is obvious that these pieces of information would beneeded if the task or the domain of application were different (forexample, manufacturing).Both atomic and complex products have to be described by meansof properties and features characterizing them. For example, a keyboardcan be described by its make, model, price, language, etc. Thisis not peculiar just of the atomic objects, also complex object arepartially described by features such as make, cost, etc. However, themain characterization of a complex object is obtained via relationswith its parts and the constraints that have to be satisfied by the parts.For example, a PC has as part one (or more) hard disk, a CPU, etc. Ifa PC has a hard disk of type SCSI and a motherboard of type EIDE,then a controller SCSI is needed. These constraints have to be explicitlyrepresented in description of complex products.Because of the importance of the relation between a (complex)product and its parts, this relation has a special status and is modeledvia the introduction of ”has-part” relationship. For our purpose itis sufficient to introduce only one kind of has-part relation (the onebetween each complex and its components) and we can consider itas an antisymmetric and transitive relation (for the issues raised bythe transitivity of part-whole relations see also [12, 7, 3]). has-part istherefore the basic mechanism for defining the partonomy betweenthe products described in the domain. However, also taxonomic relationshave to be defined in order to allow the definition of morespecific or more general concepts. For example, in our domain wewant to describe that there are different kinds of printers such as inkjet printers and laser printers. This requires the introduction of relationsof superclass and subclass for capturing the taxonomic relationand consequently of appropriate mechanisms of inheritance.3 The Conceptual Language !#"%$We present here a language to describe the classes (both of atomicproducts and of complex products) and the relationships amongthem. As concerns the individuals (i.e. the instances of the classes),we shall briefly describe their representation in section 4.The conceptual language ¢¤£¦¥ (Frames, Parts and Constraints) is,on one hand, a simple frame-based language able to represent taxonomicrelations among classes. On the other hand, ¢¤£¦¥ offers thefacility for building partonomies to describe the structure of complexobjects in terms of their parts. Moreover, ¢¤£¦¥ is enriched witha powerful language for expressing complex constraints among thecomponents and the sub-components of complex objects.Each frame represents a class of objects and it is characterizedby a type: atomic or complex for the classes of atomic or complexproducts (respectively). Besides the type, each frame & contains thefollowing information:– its name: the name of the class that it describes;– the slot superclass contains the name of the frame that representsthe direct superclass (if any). It is worth noting that the superclass isunique since we do not allow multiple inheritance for sake of simplicity.– the slot subclasses contains the names of the frames which representthe direct subclasses (if any) of the class 2 . We assume that if aclass has more than one direct subclasses, these are two by two disjunct.Moreover the slot subclasses has the facet partitioned whoseboolean value denotes whether the subclasses mentioned in the subclassesslot form a partition of the class.The slots superclass and subclasses express the subsumption relationshipamong classes: a class is subsumed by its superclasses (bothdirect and indirect) and it subsumes all its subclasses (both direct andindirect). A class is trivially subsumed by itself.The description of the class is made possible by a set of slotswhich are subdivided into own slots and member slots, following[5]. While the own slots are used for modeling the attributesof the class as a whole (as the ”average price” of an hard disk), themember slots describe the attributes of the objects belonging to theclass (e.g. the make of each CPU in the CPU class) and are inheritedby any subclass from the superclass. Each slot has a name; memberslots are characterized by a type: descriptive or partonomic. Slots ofthe latter type are used to represent has-part relations, whilst the onesof the former type are used to represent all the other kinds of objectattributes. The atomic frames cannot have any partonomic slot.Besides the type and the name, each member slot has the facetsCardinalityMin, CardinalityMax (that take values in the set of nonnegative integers) and ValueClass that can take as value a class describedby a frame or a subset of a pre-defined set. It is worth pointingout that the formalism imposes a strict inheritance since no exceptionis admitted following the tradition of KL-ONE like representationformalism ([4]). However, the formalism provides a mechanism forrestricting slots along the taxonomy by putting stricter constraints onCardinalityMin, CardinalityMax and/or ValueClass.For each descriptive member slot, '(¨©)¦¨** can be assignedto a subclass of a pre-defined class (such as integers, reals, strings orbooleans) or to a frame.To be precise, we should always distinguish between a frame, which is alanguage element, and the class that it describes. However, in order to simplifythe presentation, we will use the words frame and class as synonyms.51

‘{~o{6{Á{0{{{{{{{{{{{{For each partonomic member slot, ValueClass must be assignedto a frame (either atomic or complex). Thus, any partonomic memberslot can be viewed as a link between two frames 3 . Moreover,for the sake of simplicity, any complex class (whose direct superclassis different from the root of the taxonomy) can’t introduceany new partonomic slot w.r.t. the set of those that it inherits fromits superclass. Given a knowledge base ,.- and a complex classin ,.- , we call slot chain (starting in ) ) any sequence /#0)1 + 4343434517698;:=@ of member slots such that in ,.- there are§21the A) + 4343434B) 6DC 4E set of complex classes and the ) 6 class (eitheratomic or complex) such )GFH8I>(J?9JK:MLN>O@ that has a partonomicmember slot 1PF named (possibly inherited) '(¨©)¦¨** whose isFRQ and ) 6 has a member slot (either descriptive or partonomic)and possibly named1 6 inherited) 'S¨©)¦5¨*T* whose is a U set U .is called the codomain of the / chain starting ) in and we indicateit V4WX8;) Y/@ with .Because of their importance for the constraint language and for theinference mechanisms, we give a precise semantic for the memberslots and for the sets of slot chains.Given a ) class , each member * slot ) of represents a relation) from to the U class assigned to the 'S¨©)¦5¨*T* facet * of . Ifthe * slot )¦¨4X©:¨©©Z[?:.0?\ has )¦¨4X©:¨©©Z[]¨^.0_: and ,8à¨Nbc)(@d8;*e8©¨@¤fgUih.\jJlk *8©¨@4kmJn:7@ then 4 . In this case, we)poGFq678;)r§;*TI@s0n\write )poGtdu8;)¦4§;*I@(0i: and . We say that the§;\%Y:7 pair and the U set are, respectively, the cardinality restrictionand the value restriction for (or the codomain of) the * slot .The semantic of a member slot is naturally generalized to anyslot chain: a slot /?0v§21 1 + 343341 6 S8;:wO@ chain starting inand such that VWX8;) B/@N0yU represents the relation composition) from to D. Moreover, the set)1 6%z 1 6C z 34343 z 143433Y/o E 8;\}@ of slot chains (each starting in ) )0|A/represents the relation ~ ounion /F FR ) from V4WX8;) @#0toV4WX8;) Y/ F @ . FR) Let be a complex class 1 and one of its partonomic slots. If0‚\ , )GoGtdu8;)¦4§21PI@ 0‚: and V4WX8;)¦Y§217I@ƒ0„U , it)GoGFR6€8;)¦4§21PI@means that any complex object belonging to the ) class has a set ofcomponents belonging to the U class in a number that ranges \ from: to . Such components could be atomic objects or complex objects:in the former U case is an atomic class, while in the U latter is acomplex class.Exclusivity Assumptions on Parts: For each pair of complex classesand ) + (possibly ) †… ) + ), the following hold:)– 1 if 1 + and are two different partonomic slots ) of , 8àV b then@d821 8©V @ˆ‡(1 + 8©V @m0]‰@ ;)– 1 if 1 + and are two partonomical slots ) of ) + and respectively1 †… 1 + Y©Š7) s… ) + (possibly ), 8àV b.) @d8`V + b.) + @d8©V ƒ‹ …then+sŒ 1 8©V @7‡S1 + 8©V + @H0K‰e@ .VIt should be clear that one important consequence of the precedingassumption is that if two different instances of complex objects sharea same component, then one of them contains the other. Moreover,on the basis of this assumption, we can generalize the cardinalityrestriction concept both to the slot chains and to the sets of slot chainsin the following (/ way and are defined above):– { Y/@ 0]Ž FR )GoGFR6€8;)GF4§21PFI@ ;)GoGFR6€8;)– ) oGFR6 8;) No cycle (possibly involving also ”subclass links”) is allowed.As in the case of frames, we should distinguish from the slot, which is a languageelement, and the relation that it represents. However, to simplify thepresentation, we use the slot name also to indicate the relation representedby the slot. The simplification adopted for slot chains is analogous.@m0? o Fq ) oGFR6 8;) Y/ F @ .The case of the maximum cardinalities is analogous.Summarizing, each knowledge base consists of (at least) two differenttaxonomies: one for the classes of complex products and anotherfor the classes of atomic products; each taxonomy is a treebecause we restrict to single inheritance. A distinctive feature of the¢¤£¦¥ concerns the treatment of has-part relation by means of theintroduction of partonomic slots.3.1 Constraint LanguageEach frame modeling a complex class )contains a set (possiblyempty) of constraints that specify those restrictions on the componentsand the sub-components of the objects in ) that couldn’t beexpressed using only the cardinality and the value restrictions for themember slots.Let ) be a complex class of a knowledge base ,.- and )() its setof constraints. Any constraint in )() is of the form ’.“•” , where ’is a conjunction of predicates or the boolean constant true and ” is apredicate or the boolean constant false. The meaning is that for everyobject V in ) , if V satisfies ’ then it must satisfy ” . This must be truefor each constraint in )() . It should be clear that if ’–0]—˜ˆš , then,for each object in ) , ” must always hold, while if ”#0K› œžŸ4š , then,for each object in ) , ’ can never hold. The constraint —˜ˆšƒ“x›IœažŸ4šis meaningless.Due to the space limitations, we describe here a simplified versionof the constraint language that we actually defined and implemented.The basic building blocks of the constraint language are thepredicates. Let { 0 A/ 4343434B/o E 8;\¡< >@ , where each /F–0both the set of slot chains and the relation that it represents. Wehave six kinds of predicates for C 5 :8 1)§21 F¢ 434331 F£ d8; 6 O@ is a slot chain starting in ) . We indicate withnon negative integers ¤%JN¥ with .8 2)a class.3) 8. @d8©¤ˆI¥a@satisfies the predicate iff ¤#JnkV¦b#)8©V@4kJ§¥ , where ¤ , ¥ are@d8;©:7¨@ . ¨¦0©¨ Hª 3343 ª ¨T«Y8;* @ and each ¨4F8;H0¬>43343Y*@ issatisfies the predicate iff { 8©V@Gf®¨ .V¦b­)8;* Y @I@P334348;©:7¨¯R°±48;*¯R°±dYI¯R°±I@I@I@ . S . ¨¯ F ± 0?¨ ¯ F ± ª@d8I8;:7¨¯ F ± « 8;70§>433434@ and each ¨ ¯ F ± ² 8³S0_>343434B*T@ is a class.34343¨satisfies the predicate iff ´ °Fq 8;*¯ F ±GJ?k 8©V@‡¦¨¯ F ±IkJ®I¯ F ± @ .V¦b­)8;µr8 @I@ T·m1¦: 4) . ©m1.b­A0 4¸(4¹(J(4< E . : is a number and{V4WX8;)¦satisfies the predicate iff 8; Fº» V¦b­) @ ©m1¤: .5) 8;µr8 @I@ T·m1N8;µ¦8;½H@I@ . ½ is a set of slot chains starting in )¯R¼©±@ is a numeric set.‹ 8;½8;/F©@¦0i8;/ ² @ 6) /F . / ² 8;/F ‹ 0w/ ² @ and are two role chains starting in. V4WX8;)r / F @ and V4WX8;)¦ / ² @ must be of the same kind.)satisfies the predicate iff /F8©V@s0n/ ² 8©V@ , where /F8©V@ andV¤b])² 8©V@ are, in general, two multisets./@ . It is analogous to the predicate 4.VVn0¾’ “ ” Let ¿ and be a constraint and a predicate forthe complex ) class in a knowledge ,À- base , respectively.In the predicates, ¦éÄIÅ , ƈéÄIÅ and the various Ç F éÄIÅ can be, in general, multisets.We briefly give some definitions that generalize the equality and theinclusion relations as well as the cardinality and the intersection operatorsto multisets. If Æ is a multiset, any element È occurs in Æ=É©ÊËÍÌYÎO÷ÈDÏ;Æ7Åtimes. Let Æ?ÐnÑÈÒ†ÉÊ5˦ÌYÎO÷ÈDÏ Æ7ÅMÓwÔÕ (Æ is a set); we have (if Ö isa multiset): Æ_ÐwÖ iff Ãq×PÈÅBÃ5É©Ê˦ÌYÎ4éÈDÏ5Æ7ŃЬɩÊËÍÌO÷ÈDÏ;ÖGÅ;Å ; Æ_ØwÖ iffÖ ; Ù Æ9Ù7Ð tTº Ú ÉÊ5˦ÌYÎO÷ÈDÏ Æ7Å ; ƤÛMÖ?Ð§Ü , such that Æ¤Û Ö?ÐÆKØÜpÅBÃÉ©ÊËÍÌYÎO÷ÈDÏ;܆Å7ÐßËÍÈTàÑ4É©ÊËÍÌdÎ4éÈÏ;Æ7ÅBÏ;ÉÊ5˦ÌYÎO÷ÈDÏ©ÖpÅÕÅ .ÜiÝ_ÃR×7ȆÞ52

òIf the taxonomic and the partonomic description ) of V4V entails), V4V (¿ ) is said á âäãÀL.—4œaˆ—4å7žåæ7çèœažç©é¤ê%ë .(¿VV (¿ If ) is consistent with the taxonomic and the partonomic description) of V4V (¿ , ) is á âˆã LÀèåP鈟çŸ4—4šé€—pç©é¤ê%ë said (otherwise,it is á âäã%L#ç©éˆèå7鈟çŸ4—4šé7—Hç©é¤ê%ë said ).Inference mechanisms have been developed that are able to singleout )pì€íwLn©¨WWTîD·V¨ the predicates/constraints and thepredicates/constraints. Such mechanisms are)Gì€íïL®:V4We:7*T©*:7sound but not complete.In each knowledge base, the )() constraints associated to a classare consistent both among them and with the taxonomic and)partonomic description ) of as well as with all the constraints associatedto the classes involved in this description. )()Moreover,doesn’t contain any constraint that the system would recognize as.)Gì€í%Lߨ©WWîV4¨Due to the novelty of the constraints, we describe the rules fortheir inheritance from a class to a subclass: )(ð let be a subclass of– V4V If is recognized ) ð ì7í L®¨©WWîV4¨ as V4V , is not (explicitly)inherited ) ð by ;– ) ð otherwise, V4V inherits in the ’ ð “ñ” ð form , ’ ð where is obtainedby deleting ’ from all the predicates recognized )(ð ì€í L as) .. If, after this deletion, no predicate remains, ’ ð is the¨aW5WTîV4¨constant true. ” If is recognized )(ð ì€í Lï©:V4W:7*©*:7 as ”9ð , is the› œžŸ4š constant , ”=0c”9ð otherwise, .It should be clear that the previous rules provide a way to reducethe redundancy in the constraint inheritance and to avoid some uselesscontrols to the inference mechanisms.4 Inference ServicesThe inference mechanisms defined on the ¢¤£¦¥ language have totake into account the role of a recommending system in a virtual storewhere products have to be configured. It is important to note that insuch kind of applications there is a wide variety of customers withvery different degrees of domain expertise. The system has to supportthe naive customer by checking his/her choices of products and bysuggesting products which meet his/her requirements. However, insome cases the customer is an expert and he/she cannot be requiredto answer too many questions of the system 6 .Depending on the stage of the interaction and the kind of user, thesystem has to perform inferences on the basis of different inputs fromthe user:– scenario 1: the customer is selecting products and he/she puts themin the virtual cart. The system in order to be able to check if theproducts can work together, has to figure out what kind of complexproduct the user has in mind. The system has to use the partonomicand the taxonomic description for hypothesizing the goal of the customer.This kind of abductive inference is useful for focussing theinteraction with the user, for example for asking him/her which of aset of complex products he/she is interested in.– scenario 2: the customer has made explicit the complex productshe/he is interested in and has selected many (possibly all) componentsfor such a product. The system has to verify whether the constraintsassociated with the classes in the knowledge base are satisfiedby the current set of choices of the user and possibly suggest theinsertion of some missing components.In this paper we do not address the problem of adapting the interaction tothe different kinds of users since many of these problems have received asatisfactory solution within the SeTA system ([2]).– scenario 3: the customer is able just to provide some requirementson the product (e.g. the maximum price for a PC, ...), and possibly toindicate some specific components to be included in the product (e.g.a particular CPU, ...). In such a situation the task of the system is similarto the previous one, but an extra inference step is necessary sincethe system has to know which kind of constraints a complex productshould match in order to provide the facilities and performancesrequired by the user.Usually, the customer of a virtual store browses an electronic cataloguecontaining the description of the products sold in the store.In our case, the electronic catalogue contains both the descriptionsof the various kinds of complex products and those of the atomicones. Each atomic product appearing in this catalogue is associatedto a leaf of the atomic products taxonomy. This leaf providesthe most specific description of the product needed by the inferencemechanisms. The atomic products chosen by the customer aregrouped by their most specific class and are represented by the set3T334IV4¤ 6 E 8;:¬@ . With \ö*OV8©V4¤ F @ and \ö©I8©V4¤ F @¥7ó|0ôAV4¤we denote, respectively, the most specific class to8;¦0÷>T33434Y:7@which the atomic V4¤ F product belongs (i.e. the leaf atomic class ofthe taxonomy associated to it) and the number of such kind of productschosen by the customer. In ¥7ó there can’t be any repeated class,8àV4¤7FIV4¤ ² bø¥PóM@d8; ‹ 0ù³ Œ \ø*4V8©V4¤7F5@ ‹ 0]\ö*OV8©V4¤ ² @I@ i.e.: .To describe the inference mechanisms, we need the followingnotation. ) Let ) + and be two classes of a knowledge base. If§21 43434345176H8;:=@ is a slot chain such that:/M0/ – starts ) in ;VWX8;) B/@ – ) + subsumes ;8`ä>ƒJ#¥øJ®:ML#>@d8;úG¨GV45¨*T*äU¤@–4§21 43433417ûI@**Ta\M*ˆU h ü1¨©We:PX8;U¤@}h8©V4WX8;)û Q 434343176I@**Ta\M*ˆ) + @ ,V4WX8;UøY§21we ) Gý /Dþeÿ#) + write .We write ) ÿs) + also to indicate 8;ú/a@d8;) ý /Dþÿr) + @ that ; in thiscase, we say ) + that is more specific ) than w.r.t. the partonomy7 . It is worth noting that if any element of a ) + class can be acomponent of any element of a ) class , ) ÿ¦) + then .1. HYPOTHESIS FORMULATION. This mechanism is aimed athypothesizing which kinds of complex products a customer is interestedin, on the basis of the atomic products that he/she has put inhis/her virtual shopping cart. In particular, this mechanism individuates,among all the complex classes, those whose elements can’t haveas parts the kinds of atomic products chosen by the customer. All theother classes of products are considered as plausible hypotheses andare used either to focus the interaction with the customer and possiblychange the set of plausible hypotheses (scenario 1) or to performa set of hypothesis validation steps by means of the mechanism 2(scenario 2).The algorithm can be sketched as follows:INPUT: a knowledge base ,À- and ¥Pó 0 ATV4¤ 434343IV4¤ 6 E8;:=@¢¡¤£OUTPUT:Rank the hypotheses ¢¡¥£ in¢¡¥£ return .(the set of plausible hypotheses).according to the ÿ relation;0_A)©¨)ù©*H¨¦V4We\S1a^¦V4¨** ©: ,.-%h(üP1a¨©W:X8;)(@h¢¡¥£§¦E ;8`V4¤%bö¥7ó¤@d8;)ùÿs\ø*4V8©V¤7@I@As can be seen, ¢¡£ in there are only classes whose directsubclasses are not a partition of them. This means that the hy-If is a class, eÈÉÊ5ÉÊÌÃGÅ iff the direct subclasses of (if any) are apartition of .53

{{ðpotheses in ¢¡¤£are as specific as possible w.r.t. the taxonomy.Moreover, it should be clear that if ¢¡¤£ 0 ‰ , then there doesn’texist any complex product whose components (and sub-components)are of the kinds specified in ¥7ó .2. HYPOTHESIS VALIDATION. Given a ) complex class 8 {©and)(¤%½a set of input ) constraints for (expressed in the languagedefined in section 3.1, but different from those associated to) the class in the knowledge base), the algorithm tries to build an instanceof the ) class that satisfies all the )(¤%½{ constraints .VIt is worth noting that such an instance can be built iff the set{©of con-is consistent with the whole )description of)(¤%½straintsin the knowledge base (i.e. with both the taxonomic and the partonomicdescription ) of and with all the constraints associated to thecomplex classes involved in the definition ) of ). The main idea isstraightforward: at the beginning there is only the hypothesis that theV component exists. Then, the algorithm tries to progressively assemblea set of components and sub-components in order to V build . Duringthis process, it takes into account both the description of the{ class. If this process succeeds in building theand the set )(¤%½)instance, then it returns it, otherwise it signals that the set of inputconstraints can’t be satisfied (and this proves the initial hypothesiswrong).An instance of a complex V¦b#) product can be represented as agraph with a root V representing and in which the nodes represent thecomponents and the sub-components of V . Each arc is labelled witha partonomic slot name. If two nodes \ and : (representing, say,X bßU and X + b®U + , respectively) are connected by a path from\ to : labelled §21 4343431 6 (: < > ), it means that X + b©/€8©X @ ,where /M0_§21 434343451 6 is a slot chain and U ý /Dþeÿ#U + .Thanks to the exclusivity assumption on parts (see section 3), anyinstance graph is a tree (the instance tree).The hypothesis validation algorithm starts with a tree containingonly the root representing the hypothesis V and it progressively expandsthe instance tree for V . This progressive expansion is actuallya search process in which, usually, some choices are performed. Weadopt a chronological backtracking mechanism to change the pastchoices when the tree under construction can’t grow any more withoutviolating any constraint.Rather informally, we can say that the algorithm always work witha hypothetical instance of a class ) , i.e. with an instance tree, possiblynot completely specified, that doesn’t violate neither the description) of , nor the input )(¤%½{ constraints . However, such atree can actually provide only an incomplete description of the instance.Therefore, it is possible that the truth value of some predicates(and thus of some constraints) can’t be determined for a hypotheticalinstance. Thus, it is important to stress that saying that a hypotheticalinstance doesn’t violate any constraint (either contained in the{©knowledge base )(¤%½or in ) is not the same thing as sayingthat it satisfies all the constraints nor as saying that its tree canbe expanded in some way such that every constraint will eventuallybe satisfied! A hypothetical instance whose tree can be completelyexpanded in some way that satisfies all the constraints is said an instance.Any instance whose tree is completely expanded is said acompletely described instance, otherwise it is said a partially describedinstance.{©It is clear )(¤%½that if can’t be satisfied, the algorithmends after having performed all the possible choices. If the hypotheticalinstance is really an instance, the algorithm can’t stop be-Vfore having discovered this fact. However, the number of the furhterFor the sake of simplicity, we assume È4É©ÊÉ©ÊaÌÃGÅ .instance tree expansion steps is task dependent. If the goal is toprovide a support for a complete configuration of the product, theexpansion can continue until a completely described instance isproduced. Otherwise, if the main goal is to test the consistency ofa set of constraints (as in the scenarios 2 and 3) given by the customer,a lazier approach that can return a partially described instanceis more suitable. We sketch here the algorithm in its lazy versioncurrently implemented in the prototype. The main idea is thatthe expansion of the instance tree is performed by considering onlythose slots whose cardinality and whose fillers’ classes can be{criticalfor the satisfaction of the )(¤%½input constraints . To doso, the sets ) ¼and £¼are associated and maintained for each component.The former initially contains all the constraints bound to theinput ones 9 . After an expansion step, ) ¼is updated in order to removefrom it the constraints that became satisfied. The set £¼iscomputed on the basis of ) ¼and it contains all the slots that caninfluence the truth values of the constraints in ) ¼. A constraint propagationmechanism is used to reduce the number of the alternativesproduced by the functions computeAdmissibleCardinalities(1 ) and).computeAdmissibleClasses(\ Let be the instance tree V bï) for , containing only the root (inthe following it intended that the BACKTRACKING call returnsthe failure message if no alternative choice is possible).INPUT: a knowledge base ,À- , , )(¤%½{©.OUTPUT: an instance tree for the V]b‚) instance or the failuremessage.{©@d8©V4Vä©*ˆ4V4WTîD:€! X ¨*H)Gì€í†Lƒ©:V4W:7*©*T©:€;@if 8;úV4V¦b­)(¤%½then return{FAILURE;Let )(¤%½ be from which the constraints)(¤%½) ì€í Lߨ©WWîV4¨ recognized as have been removed;ð0]‰ if then return ;)(¤%½while there is in some not marked components nodes)¹ (i.e. )(¸do beginchooseComponent( := ); /*Currently handled with a : queue*/:= computeCurrentConstraints(: );¼ )¼:= computeCurrentSlots(: ,) ¼);£:= chooseSlot(£¼); /*Currently random*/1:= computeAdmissibleCardinalities(1 );V4¨4X*V¨OX*†0]‰ if then BACKTRACKING;:= chooseCardinality(V¨OX* ); /*Currently the minimumV4¨4X8217@one*/k V4¨4X*kT¹ if 1 thensave V4¨4X* LïATV4¨4X821P@ E as alternative choices ¹ ;¸violates some constraint ) ¼ ¹ in then BACKTRACKING;¸" ifExpand ¸by introducing V4¨4X8217@ new nodes, each one connectedwith : via an arc labelled1¤¹ ;for each ¸ new created node \:= computeAdmissibleClasses(\ );V4¨**4*V45¨*T*4*†0K‰ if then BACKTRACKING;¹ do begin:= chooseClass(V4¨**4* ); /*Currently random*/V4¨**8;\ø@k V4¨**4*Dk¹?> if thenendsave V45¨*T*4*GL–AV4¨**8;\ø@ E as alternative choices¹¸¼:= updateCurrentConstraints(: );)¸# if violates some constraint ) ¼ ¹ in then BACKTRACKING;¼:= updateCurrentSlots(: );££¼ 0N‰ if ¸ then mark the :ø¹component$ endThe current system relies on a formal definition of a bind relation amongconstraints.54

{{8{return T% .Translation of the Set ¥Póin a Set of Constraints. As concernsthe scenario 2 depicted at the beginning of this section, thetask of controlling that the set of components chosen by the customer(and represented by the set ¥7ó ) can actually be parts of a complexproduct of kind ) (i.e. belonging to the class ) 10 ) can be performedby the hypothesis validation algorithm. Therefore, there is the{ needof input constraints forthe ) class . This can be done in the following way:to translate the set ¥7ó in a set )(¤%½{for V¤øbø¥Pó each do begin)(¤%½¦20N‰ ;0]A/'¨) ý /Dþÿ#\ö*4V8©V4¤7@ E ;8©V¤7@&¦¦20 )(¤%½)(¤%½ª A—˜ˆš “{©optdu 8;)¦ 8©V4¤P@I@I@I@I@ E8©V¤7@I@d8I8;©:(\ø*4V8©V4¤7@8;\ö©I8©V4¤7@dY){end.It should be clear (see the description of the predicate 3 in section{3.1)asthat the algorithm 2, with the ) class and this )(¤%½ setinputs, verifies if it is possible to build an V(b%) instance containingat \ö©I8©V4¤7@ least elements of \ö*OV8©V4¤7@ kind , for V4¤gbi¥7óeachchosen by the customer. Moreover, if such an instance is possible, allthe components that were not chosen by the customer, but that havebeen added during the expansion of the instance tree, can be the basisfor suggesting some needed components to the customer.We just point out that the ) class could have been indicated by thecustomer autonomously or after a dialogue with the system on thebasis of the results of the hypothesis formulation algorithm.5 ConclusionsIn the present paper we have described the main features of ¢ £¦¥ ,in particular the role played by has-part relations and constraints inmodeling complex product. We have also sketched some basic reasoningmechanisms which can be exploited to support a customer inselecting and configuring a product. The adoption of a declarativeapproach to knowledge representation has the advantage of makinga clear distinction between the formalism and the reasoning mechanisms.¢¤£¦¥ is powerful enough for modeling different types ofknowledge, in particular the relations between a complex productand its components as well as the descriptive characteristics of theproducts. This ability is very relevant since in a business to consumerperspective of e-commerce a recommending system has also the taskof making intelligible to the customer the description of the product.For this reason the products cannot be described just by means oftechnical features, but a description should include also economic,functional, aesthetic features. The recommending system has to usethese pieces of information for selecting and ranking products to besuggested to the user, but can also use these pieces of informationfor customizing the description of the product by taking into considerationthe user profile (see, for example, [2]). In the paper wehave focussed our attention to the needs of the customer, but we alsohave started to consider the services useful to the manager of thevirtual store. For example, we have developed some additional inferencemechanisms able to single out some type of inconsistency inthe knowledge base. These mechanisms are quite useful to knowledgeengineers when the knowledge base has to be updated and/orextended or a new domain has to be modeled.It is worth noting that even if the representation language and theinference services that we described are tailored to the representation(Again, we assume È4É©ÊÉ©ÊaÌÃGÅ .of (and to the reasoning on) products in a virtual store, they have afew similarities with some mechanisms used in the technical configurationtask. In [11] the Generative Constraint Satisfaction Problem(GCSP) approach is presented and in [6] a configurator for large telephoneswitching systems based on the GCSP paradigm is described.Although in the framework that we proposed the configuration (or thetesting of the user requirements consistency) task is not defined as a(G)CSP, the hypothesis validation algorithm does actually work overa set of variables representing slots and components whose numbercan’t be predetermined. The activation of the slot variables is dynamicallyperformed by the function computeCurrentSlots(: ,) ¼) and itis analogous to the activation of the property variables in GCSP.However, in our framework, the activation constraints are implicitlycontained in the partonomic description of the classes 11 . The activationof new components variables is based on the value chosen for(the cardinality of) a (current) slot and it represents the instance treeexpansion step. As the problem solver described in [11, 6] for theGCSP, the hypothesis validation algorithm is based on a backtrackingarchitecture in which some constraint propagation mechanismsare used to reduce the set of possible choices (i.e. to reduce the domainof the slot and of the component variables).Moreover, the semantic of frames and that of member slots(chains) follow that of description logic (DL) terms (a DL-based configuratoris described, for example, in [8]). However, differently frommost DL-based systems, our system doesn’t include a classificatorand the taxonomies have to be explicitly built by the knowledge engineer.REFERENCES[1] M. Albers, C. M. Jonker, M. Karami, and J. Treur, ‘An electronic marketplace: Generic agent models, ontologies and knowledge’, in Agent-Based Decision-Support for Managing the Internet-Enabled Supply-Chain, (1999).[2] L. Ardissono, A. Goy, G. Petrone, and M. Segnan, ‘Adaptive user interfacesfor on-line shopping’, in Proc. of the Adaptive User InterfacesSpring Symposium of AAAI, (2000).[3] A. Artale, E. Franconi, N. Guarino, and L. Pazzi, ‘Part-whole relationsin object-centered systems: An overview’, Data and Knowledge Engineering,(20), 347–383, (1996).[4] R. J. Brachman and J. G. Schmolze, ‘An overview of the kl-one knowledgerepresentation system’, Cognitive Science, (9), 171–216, (1985).[5] R. Fikes and T. Kehler, ‘The role of frame-based representation in reasoning’,Comm. ACM, 28(9), 904–920, (1985).[6] G. Fleischanderl, G. E. Friedrich, A. Haselböck, H. Schreiner, andM. Stumptner, ‘Configuring large systems using generative constraintsatisfaction’, IEEE Intelligent Systems, (July/August 1998), 59–68,(1998).[7] P. Gerstl and S. Pribbenow, ‘Midwinters, end games, and body parts: aclassification of part-whole relations’, Int. J. Human-Computer Studies,(43), 865–889, (1995).[8] D. L. McGuinness and J. R. Wright, ‘An industrial-strength descriptionlogic-based configurator platform’, IEEE Intelligent Systems,(July/August 1998), 69–77, (1998).[9] B. Raskutti, A. Beitz, and B. Ward, ‘A feature-based approach to recommendingselections based on past preferences’, User Modeling andUser-Adapted Interaction, (7), 179–218, (1997).[10] P. Resnick and H. Varian (Eds.), ‘Recommender systems’, Comm.ACM, 40(3), 56–89, (1997).[11] M. Stumptner and A. Haselböck, ‘A generative constraint formalism forconfiguration problems’, in LNAI 728, pp. 302–313, (1993).[12] M. E. Winston, R. Chaffin, and D. Herrmann, ‘A taxonomy of partwholerelations’, Cognitive Science, (11), 417–444, (1987).IDue to the lazy policy of the algorithm, not all the partonomic slots of aclass are introduced for each component belonging to that class and occurringin an instance tree.55

Configurable Software Product FamiliesTomi Männistö 1 , Timo Soininen 1 and Reijo Sulonen 1Abstract. Product configuration is a specific area of research andbusiness for mechanical (and electrical) products. However, configurablesoftware products have not attracted as much interest. Thispaper outlines the concept of configurable software product familiescovering millions of variants from which product individuals areconfigured to meet particular customer needs. Solutions to managingsuch software products are sought from experiences with mechanicalproducts and expressed here in the form of a researchagenda.1 INTRODUCTIONThis paper investigates software as a configurable product familythat may include millions of variants. Thus, we aim at providingmethods and tools for a software engineering paradigm in whichinstances of software are created in a routine manner. This creationwould be based on a predefined model (or architecture) that describesall variants and the required knowledge for selecting functionalcombinations of components. Such paradigm becomesimportant, for example, when software is embedded in a productthat is configurable and the software must adapt to the hardwareconfiguration. If the available memory is limited, the loaded softwarecannot simply include all possible variability and dynamicallyadapt to the hardware. Examples of such products are tomorrow’smobile terminals. Similar strategies are also currently sought forenterprise resource planning (ERP) systems, which are large configurableinformation system packages [1].In this paper, we chart a research agenda starting from the experiencesin product configuration of mechanical and electrical products,which are called traditional products in the following. Webegin with a brief introduction to product configuration and softwareengineering, especially software architectures. However, weassume that the reader is familiar with product configuration andthus the introduction to it is minimal.Our goal for the research work is to find description methods forsoftware product families. The methods should be understandable tosoftware engineers with no special skills in formal methods or logic.In addition, the description of a software product family of an industrialcompany should be manageable both in complexity and insize. This restricts the modeling essentially to the design level, asvery deep models tend to be extremely large. Furthermore, the useddescription language should allow the models to be processed bycomputers, which requires strict tradeoffs between the expressivityand complexity of the underlying concepts, as the more powerfullogical formalisms may in practice be infeasible.With respect to previous work in software engineering, a naturalcounterpart to which this research should be contrasted is modelingand applying software architectures. We aim at rather limited modelsif compared to the most general approaches in software engineeringbut, on the other hand, we aim at general concepts that arenot specific to any particular software domain.2 PRODUCT CONFIGURATIONA configurable product is adapted to the needs of a particular customerin a configuration process using predesigned components anda predefined configuration model. A configuration task is thus tofind a suitable variant from the search space defined by the configurationmodel. The output of a configuration process is a configuration,which is an adequate description of the product individual sothat it can be manufactured (see Figure 1) [2,3,4,5,6,7].3 SOFTWARE ENGINEERINGIn this section, a brief look is taken at the basic concepts in softwareengineering, in particular those of software architectures. We beginbriefly with component based software, move on to software architecturesand concentrate there on software architecture descriptionlanguages and domain specific software architectures, which providethe central point of reference for this paper.Within component-based software engineering (CBSE), definitionsof a software component include [8]:• nearly independent and replaceable part of a system with aclear function in the context of a well-defined architecture• dynamically bindable package that is accessed throughdocumented interfaces• unit of composition with contractually specified interfaces• business component representing an autonomous businessconcept or process.In many cases, components are seen as rather independent units andit is required that truly composable systems allow connecting systemcomponents into a whole in ways not foreseen by the originaldevelopers of the components [9].Software architecture is a term understood in many differentways, typically meaning the structure of components of a softwaresystem, including the relationships and guidelines for design andmanagement of evolution [10]. According to Moriconi et al. [11], asoftware architecture is represented by the following concepts:• component• interface that denotes a logical point of interaction between acomponent and its environment• connector, relating interface points, components or both• configuration, which is a collection of constraints that wireobjects into a specific architecture• mapping from the language of an abstract architecture to thelanguage of concrete architecture• architectural styleArchitectural style is defined by a collection of conventions for aclass of software architectures. Style is thus more a general theoryfor a subfield of software engineering. Common architectural styles1 Helsinki University of Technology, TAI Research Centre and Laboratoryof Information Processing Science, P.O. Box 9555, FIN-02015 HUT, Finland.Email: {Tomi.Mannisto, Timo.Soininen, Reijo.Sulonen}@hut.fi56

include pipe-filter, batch-sequential, blackboard, implicit invocation(event-based) and client-server [11]. Formal methods allow analyzingproperties of styles and result to a set of general theoremsabout all systems in the family [12].Software architecture description languages (ADL) are used tosupport architecture-based system development. A system architectureor architectural model is specified by a set of components,connectors, a configuration and a set of constraints and is written inan architecture description language [13]. An architectural modelmay apply to a single system or to a family of systems in a domain;the latter is referred to as a generic architecture or domain specificsoftware architecture (DSSA) [14], which comprises of [15]:• reference architecture describing a computational frameworkfor a domain of applications• component library of reusable chunks of domain expertise• application configuration method for configuring componentsto meet particular application requirementsThe focus of this paper is on software product families that includelarge variation. Variety in software product families can be implementedby an approach called customization, in which a ‘universal’software product is adapted to behave as any specific variant [16].However, the size of the software product increases because it containsall the variability of the product.An alternative approach is to use preprocessor directives to optionallyinclude pieces of source code. In this approach, however,the big picture is easily lost, as the representation of variation is notexplicit but is embedded in the source code. Variability may also beachieved by modularization, in which the variants are produced byselecting appropriate components to the family architecture [15,16].When large software products are adapted to different customers,a typical approach is “copy and paste”, also called cloning. That is,an existing variant of the software product is taken as a basis andthen modified accordingly. This approach has its drawbacks since induplication and ad doc modification of architectural components theoriginal ideas behind the architecture are easily lost, which in consequencedeteriorates the overall product architecture [17].4 CONFIGURING SOFTWARE4.1 Feasibility of Configuring SoftwareSome issues specific to software might make configurable softwareproducts infeasible. For example, including extraneous componentsdoes not typically increase the cost of a product individual. Thisenables in many cases the selling of software product individualsthat contain all possible features. Sometimes, however, the availablememory is a limiting resource. In such case, it may be necessary tocarefully select the components in a particular configuration simplybecause otherwise the product individuals would not fit into thememory.In mobile communication, there are also limitations in bandwidth,which may become an important factor if the software productindividual is transferred via a wireless communication channel.Therefore, it may be important to load the exact software variant forthe hardware in question and take into account the hardware andother software options already installed into the product individualto avoid unnecessary usage of bandwidth.The current generation of ERP systems relies on a monolithicsoftware architecture in which customer requirements are met by alarge number of parameters, options and configurable functionality.57However, a minimalist strategy based on components is an alternateway to meet situation-specific requirements [1].The common point in all these cases is that customer specificvariation of software is needed but it should be implemented byother means than single monolithic software product.4.2 Comparison to Mechanical ProductsThere are three major product processes: development, orderdeliveryand after-sales. The processes and their results are illustratedin Figure 1. For configurable products the order deliveryprocess is required to be smooth and not to include any designwork, which is carried out in the development process. Many companiesmanufacturing project-like traditional products have recentlysought ways towards this kind of operation, i.e., product configuration.Similarly, software engineering can find ways towards orderdeliveryprocess that would provide customer specific solutionswithout programming.VersionmanagementDevelopmentProduct family description=configuration modelProductfamilymanagementFigure 1.reconfiguration modelOrder-DeliveryConfigurationProduct individualReconfigurationBasic product processes.CustomerServiceAfter-salesThe generic software architectures, especially DSSAs, are closerelatives to product configuration of traditional products. In bothfields the term component means very much the same and alsoconcepts ‘port’ and ‘connector’ are used, for example. In componentbased software, the components are very often seen as independententities used in manner not thought at the time they weredesigned. In traditional products there are also such components,e.g., screws, bolts, capacitors and resistors. These, however, aretypically not relevant to product configuration, in which componentsare larger chunks, also called modules, designed with theparticular product family in mind. Of approaches to software variety,the closest to product configuration is modularization.Furthermore, in DSSAs, the reference architecture with componentlibrary corresponds to configuration model and applicationconfiguration method to configuration algorithm of traditionalproducts. Configuration models of traditional products are expressedby special languages designed for configuration purposes,which have the similar basis as ADLs of software architectures.Configuration languages, however, are typically applicable to allconfigurable products; they are not targeted to specific type of configurableproducts. It is not clear what are the right concepts formodeling software product families in general. Are components andfirst-class components the right concepts [18]; or should the configurationmodel capture the dynamic behavior of the system [19];or should the configuration model be based on business processes[20]?It would be in principle possible to model the physics behind thedesign of a traditional product. For example, one could includekinematics and fluid or energy flow equations and constraints in the

configuration model. This, however, is hardly ever done, as mostcompanies do not have resources to build configuration modelsfrom physical principles Consequently, the configuration knowledgeis typically at surface, design level. Thus, the fact that a configurationmodel describes only correct product individuals cannotbe derived from the model—it is based on the designers’ capabilitiesof designing functioning product families. The development ofsome software architecture styles in the form of general theory ofsoftware engineering resembles the approaches to develop a generaltheory of design.5 PROPOSAL FOR A RESEARCH AGENDAOur proposal is based on lesson learned in research with traditionalproducts. The modeling and management of configuration knowledgeof traditional products is difficult even with a static information.That is, for example, without analyzing whether a productindividual fulfils some kinematic conditions. For configuring software,capturing the behavior of software has been proposed [19].That is an important line of research, but unlike it, we begin herewith a static situation. Regarding configuration of software productfamilies, this means that we do not suggest starting from the generaltheory of software architectures. We thus intend to investigate asmall part of the software architectures, which includes research onarchitecture description languages and domain specific softwarearchitectures in a context where large variety is central. Our workbelongs to an emerging research area of software product lines inwhich the first international conferences are currently being organized(see http://www.sei.cmu.edu/plp/conf/SPLC.html). Our idea isto approach software configuration with the methods and toolsdeveloped for mechanical products. We aim to analyze how softwareproducts can be treated with them.Our approach to managing software product families assumes• a need for customer specific adaptation in a relatively routineconfiguration process. For example, because of restrictionsin the size of the available memory.• the software product to consist of components (or modules)that have clear interfaces• existence of domain specific software architecture, or inother words, a configuration model, that describes the variantsof the software product family• a language for modeling the above mentioned componentsand the architecture, i.e., a configuration modeling language.The management of a software product family would be done independentlyof the details of the process producing the software. Thisprocess may include selection of correct software modules, settingvalues for pre-processor directives, textual means (e.g., macros) formodifying the source code, selecting module versions from versionmanagement tools, creation of scripts for compiling and linking theexecutable, etc. The point is that the management is based on aconfiguration model at the architectural level. That model serves asa tool for the development and management of product family andfor the actual configuration of software product individuals. Theresearch tries to provide answers to, e.g., the following questions:• How should the architectures and components of softwareproduct families and their evolution be modeled?• What kind of intelligent support for re-using architecturesand components and configuring software can be offered?• How does the (dynamic) reconfiguration affect the situation?What does it enable?ACKNOWLEDGEMENTSWe gratefully acknowledge the financial support from TechnologyDevelopment Centre of Finland (Tekes) and Helsinki GraduateSchool of Computer Science and Engineering (HeCSE).REFERENCES[1] K. Kumar and J. van Hillegersberg, ‘Enterprise resource planning—experiences and evolution’, Communications of the ACM, 43, 22–26,(2000).[2] S. Mittal and F. Frayman, ‘Towards a generic model of configurationtasks’, in: Proc. of the 11th International Joint Conference on ArtificialIntelligence (IJCAI), 1395–1401, 1989.[3] T. Männistö, H. Peltonen, and R. Sulonen, ‘View to product configurationknowledge modelling and evolution’, in: Configuration—papersfrom the 1996 AAAI Fall Symposium (AAAI technical report FS-96–03), B. Faltings and E.C. Freuder, eds. AAAI Press, 111–118, 1996.[4] T. Darr, D. McGuinness, and M. Klein, Special Issue on ConfigurationDesign. AI EDAM 12, (1998).[5] B. Faltings and E.C. Freuder, Special Issue on Configuration. IEEEintelligent systems & their applications 13, (1998).[6] H. Peltonen, T. Männistö, T. Soininen, et al, ‘Concepts for modellingconfigurable products’, in: Proc. of the Product Data TechnologyDays, Quality Marketing Services, 189–196, 1998.[7] T. Soininen, J. Tiihonen, T. Männistö, and R. Sulonen, ‘Towards aGeneral Ontology of Configuration’, AI EDAM, 12, 357–372, (1998).[8] A.W. Brown and K.C. Wallnau, ‘The current state of CBSE’, IEEESoftware, 15, 37–46, (1998).[9] M. Shaw, R. DeLine, D.V. Klein, et al, ‘Abstractions for softwarearchitecture and tools to support them’, IEEE Transactions on softwareengineering, 21, 314–335, (1995).[10] D. Garlan and D.E. Perry, ‘Introduction to the special issue on softwarearchitecture’, IEEE Transactions on software engineering, 21, 269–274, (1995).[11] M. Moriconi, X. Qian, and R.A. Riemenschneider, ‘Correct architecturerefinement’, IEEE Transactions on software engineering, 21, 356–372, (1995).[12] G.D. Abowd, R. Allen, and D. Garlan, ‘Formalizing style to understanddescriptions of software architecture’, ACM Transactions on softwareengineering and methodology, 4, 319–364, (1995).[13] J.J.P. Tsai, A. Liu, E. Juan, and S. Avinash, ‘Knowledge-based softwarearchitectures: acquisition, specification, and verification’, IEEETransactions on knowledge and data engineering, 11, 187–201,(1999).[14] P. Kogut and P. Clements, ‘Features of architecture description languages’,in: Proceedings of Software Technology Conference, 1995.[15] B. Hayes-Roth, K. Pfelger, P. Lalanda, P. Morignot, and M. Blabanovic,‘A domain-specific software architecture for adaptive intelligentsystems’, IEEE Transactions on software engineering, 21, 288–301,(1995).[16] A. Karhinen, A. Ran, and T. Tallgren, ‘Configuring design for reuse’,in: Proceedings of International Conference on Software Engineering,ICSE’97, 701–710, 1997.[17] D. Dikel, D. Kane, S. Ornburn, W. Loftus, and J. Wilson, ‘Applyingsoftware product-line architecture’, Computer, 30, 49–61, (1997).[18] J. Bosch, ‘Evolution and composition of resusable assets in productlinearchitectures: a case study’, in: Software architecture, P. Donohoe,ed. Kluwer Academic Publishers, 321–339, 1999.[19] C. Kühn, ‘Requirements for configuring complex software-basedsystems’, in: Configuration—Papers from the 1999 AAAI workshop, B.Faltings, E.C. Freuder, G.E. Friedrich and A. Felfernig, eds. AAAIPress, 11–16, 1999.[20] A.-W. Scheer and F. Habermann, ‘Making ERP a Success’, Communicationsof the ACM, 43, 57–61, (2000).58

Yet Another Approach to CCSP for ConfigurationProblemMathieu Veron 12 and Michel Aldanondo 3Abstract. Industry interest concerning the configuration problem isgetting bigger and bigger each year. Among the research axes raisedby this activity, the search for a suitable formalism for configurationproblem led to the definition of Conditional Constraint SatisfactionProblem. A CCSP could be briefly described as an auto-modifyingCSP, variables and constraints are added or removed according toconditions on the current state of activity of variables. This leads totwo separate types of constraints and to a two level algorithm.We believe that the modeling of a configurable product must includeand manage an activity state over each object used in the representationof such a product. So we are inclined to use the CCSPframework. But, there is a certain amount of drawbacks in using thisapproach. After a short summary of the main problems encountered,we will present another approach, able to represent the same class ofproblem but in a single CSP.The choices made for this modeling will be justified and illustratedby an example. Furthermore, we will present an algorithm to solvethis problem, this algorithm is able to take advantage of the natureof variable. To conclude, we will comment some preliminary resultscomputed on real and randomly generated configuration problems.1 IntroductionNowadays, Constraint Satisfaction Problems framework (CSP) isused widely in industrial applications. Among the emerging ones,we would like to stress the growing importance, from both industrialand scientific points of view, of the configuration problem.Configuration aims to provide a correct and complete definition ofa product containing non predefined and/or optional elements. Computers,hand-made bookshelves, travels are examples of configurableproducts. The CSP framework can help us tackling this problem,first, thanks to its compact representation of the problem. Indeed,suppliers of configurable product generally have a wide offer andmaking an exhaustive catalogue of all available configurations is outof concern. Second, due to technical, commercial or even marketingdecisions, some elements could not be combined together and shouldbe identified at the designing stage, thus the framework used to representa configurable product should be able to express constraints.Earlier works [8] have shown that, if CSP seems to be a valuablecandidate to manage the configuration problem, it could not beenused ”as-is”.1 Access Commerce, rue Galilée,BP 555, 31467 Labège, France. email :mv@access-commerce.com2 Ecole Nationale d’Ingénieurs de Tarbes, 47 ave. Azereix 65000, France.3 Ecole des Mines d’Albi, Campus Jalard, Route de Teillet, 81013 ALBI CTCedex 09, France. email : Michel.Aldanondo@enstimac.fr1.1 Link between CSP and ConfigurationWhy CSP are able to represent a configuration problem. Configurationproblems are often partitioned into two approaches : atechnical one, where the configurable product is defined by the expressionof all the parts that can compose the final product ; hencethe configuration process could be seen as the reduction from thismodel to a valid bill-of-material (B.O.M.). Variables either representthe presence (or absence) of a component or its identification code.Constraints describe the allowed combinations of items. Moreover,one can express constraints over quantity of an item if there are variablesdedicated to represent the amount of each selected item.The second approach, said functional, starts with a more descriptivemodel of the product, more suited to the end-user lacking technicalknowledge, it allows people to express their needs valuating characteristicswithout referring to parts. Variables can be used to representcharacteristics, their domains and the possible values, whereasconstraints can express the values which are compatible and thosewhich are not. Moreover, one can express constraints over numericalvalues, for example dimension, which is very useful for tailoredproducts. A mapping between the characteristics and the B.O.M. isthen established.Why they are not. First of all, there is no structure into a bare CSPwhereas configurable product knowledge is quite always organizedinto a hierarchy. Hence, if variables are used to represent characteristicsor the presence/absence of a component, they should be gatheredinto a meta-object, which could also be included in a super-elementand so on.Second, and this is one of the major differences between CSP andConfiguration problem, all the variables do not take part in the solution.Indeed, the expert knowledge about configurable product isfull of ”rules” such as : if a component of type A is selected then nocomponent of type B should be available ; taking one of the componentA implies to take one of the component C, etc. These rules canbe conveniently coded through an activity state over variable, statingthat only active variables belong to the search/solution space.From these two statements, it becomes clear that not only variablesactivity should be controlled, but also that an activity state has to bemanaged at any level in the structure.To overcome the above limitations, two main ways were explored: to manage on top of a CSP, a second problem able to compute theactivity state of each variable (work published in [4]) ; or to extendthe CSP framework in order to be able to express the structure ofthe problem, one of the most representative works was published in[5]. We will briefly discuss both approaches, and from the lessons welearnt, we will present another approach of the configuration problemmodelization and the algorithm that comes along to solve it.59

1.2 DCSPTheir works on configuration led Mittal and Falkenhainer [4] topresent the Dynamic CSP formalism, also known as ConditionalCSP (CondCSP) to distinguish from the Dynamic CSP presentedin [2]. The idea behind CondCSP is to manage an activity state oneach variable, and to allow the expression of rules to condition thisactivity. Only active variables take part in the solution. It could beformally defined as :Definition. A Conditional CSP is a triplet {V, AC, CC}.WhereV is a set of variables, AC is a base of rules as ”condition impliesvariable v is (or is not) active”, condition is a logical expressioninvolving either activity state or value of variables. CC is a set ofconstraints i.e. a subset of the Cartesian product of the domain ofvariables expressing the allowed valuations.The configuration problem is then defined as :Definition. The configuration problem is, given a CondCSP,to find a valid assignment such that all active variables satisfy allthe constraints having all their variables active.Beginning with the CSP p 0 = {V 0, CC}, V 0 ⊂ V is the subset ofinitially active variables (i.e. for which a rule like true → active : vexists)1.3 Composite CSPComposite CSP (CompCSP) were introduced by [5], as an answer tothe lack of structure into the CondCSP formalism. The idea behindCompCSP relies on abstraction. At a meta-level, the problem isonly composed of meta-variables, when they are selected, the wholeproblem is modified as the meta-variable is expanded into (andreplaced by) a less abstract CompCSP.Definition. A composite CSP (CompCSP) is a triplet {X, D,C}, where X is a set of variables, D is the set of their respectivedomains and C is a set of constraints. Elements of any d i ∈ D iseither a value or a CompCSP.Every time the domain of a variable v is restricted toa singleton representing a CompCSP p’={X’, D’, C’},the current problem is modified : p i becomes p i+1 ={X/{v} ∪ X ′ , D/{d v } ∪ D ′ , C/{C v } ∪ C ′ } where C v isthe subset of C containing constraints involving variable v.We believe that this substitution mechanism is the strength andweakness of the CompCSP formalism. Indeed it allows to take careof the structure of configuration problems and to keep the currentproblem small. But, it introduces some drawbacks.Due to the variable substitution, undoing a choice (i.e. backtracking)is more complicated than in classical CSPs. One needs to keeptrack of the meta-problem structure to undo choices and to removevariables and constraints. Moreover, in an interactive configurationframework, we need to keep all the choices made by the user ”onscreen”. It is possible to implement this functionality in the CompCSPframework, but doing so, we loose the good small size property.Regarding storing space and computing time issue now, someovercost due to ”implied constraints” extrapolated from constraintsgiven at the variable level might appear. Symmetrically, constraintsexpressed at the meta-level should be specialized at sub-level because,when the substitution occurs, all the constraints on this variableare removed from the new problem.2 Modeling the Configuration Problem on a singleCSPIn order to take the best of both worlds (expressiveness and structure),another definition of a configuration and configurable productwill be given, then we will propose a way to encode it into a CSP.2.1 Proposed model of the configuration problemLet us start with the core definition, explanations will follow :Definition. A configurable product (CP for short) is a triplet{L, V, C} where,L is a set of CP, which can be partitioned in L = L cp ∪ L cpe respectivelycontaining non-elementary CPs (L ̸= ⊘) and elementaryones (L = ⊘). Cardinality of L is n.V is a set of variables, which can be partitioned in V = V s ∪ V brespectively containing state variables and base variables (i.e. theclassical ones). Cardinality of V b is m, whereas cardinality of V s isn + m.C is a set of constraints that can be partitioned in C = C s ∪C b ∪C sb ,respectively containing constraints involving only state variables,constraints involving only base variables and constraints involvingboth types of variables.The structure is given by the recursive inclusion of CPs withinCPs. It is commonly admitted that keeping this structure tree shapedis safer. We encourage the use of a restriction rule within thedefinition not to allow circular inclusion of CPs. In the following,we will assume that all the manipulated CPs satisfy this condition.State variables are Boolean variables, one for each CP and variablerecursively included into the CP root. By definition, the value {0}encodes the inactive state, while the value {1} encode the active one.Conditional rules over activity state are transposed into constraintsinvolving state variables, for example : two elements A and B (eitherCP or variables) mutually excluding each other, or, if the use of Aimplies the use of B, see table 1 for examples.Table 1.Condition Rules encodingA excludes BA implies BState(A) State(B) State(A) State(B)0 0 0 00 1 0 11 0 1 1both A and B or noneState(A) State(B)0 01 1Whereas the CondCSP formalism used a two-level model and atwo-level algorithm, we are now able to use CSPs classical algorithmssuch as propagation and resolution to solve the configurationproblem. The advantages are numerous :• It is often more compact than a rule based approach to encode theactivity rules into constraints.60

• Due to the attachment of constraints to CPs, the knowledge baseitself is structured and CP re-utilization is easy.• The good small-size property of CompCSP remains because onlyactive variables participate in the solution and the resolution process.• The transformation from CondCSP to this new modeling approachcan be automated.• It is possible to express the optional characteristic of a CP or variable(the one for which 0 and 1 are still valid into the domain oftheir state variable).But more important is that, the same efficient algorithm is used forall kinds of variables, so we are able to :• Deduce active and inactive CPs or variables thanks to constraintpropagation.• Explanation mechanisms [7] can be extended at no cost from valueremoval to state enforcement.• The variable partition allows to decompose the constraint probleminto three sub-problems (P s , P b , P sb ) on which we can enforce adifferent level of consistency.• A resolution algorithm, while listing all the solutions of the configurationproblem can exhibit the values that never appear intoa solution. This can be done in a preprocessing step to obtain anequivalent and reduced problem.2.2 AlgorithmWe will propose in this section, an algorithm to solve the configurationproblem. It is based on Dynamic Backtracking [3] + local consistency,but contains some modifications. First the three sub-problemscan be treated in a row, with different levels of consistency (availableconsistency are : one pass arc consistency (i.e. Forward Checking(FC)), Arc-consistency (AC) and Singleton Arc-Consistency (SAC)).Second, as constraints involving at least one non-active variable aretrivially satisfied (in that case the constraint itself is said inactive),the propagation only occurs on active constraints. And last, a variablebecoming active (respectively non-active) should be put in thepropagation (resp. relaxation) pipe.main programi=0definition of problem Pipartition of Pi in Pis, Pisb and PibFiltrate each constraint of Piif inconsistent then exit on errorelseloopif in interactive modewait for a user unary constraint(i.e. a choice of a value (val)over variable (var))elseif in batch mode thenselect a variable (var)select a value (val)i++Filtrate(Pi, var, val)if Pi is not consistent thenif in a batch mode thenbackjump, heuristically preferstate variableelse if in interactive mode thenexplain inconsistencyand/or propose a restorationend loopfunction Filtrate(Pi, var, val)push var into list Lwhile L is not emptyv = pop(L)if v is in Pis or Pisbfiltrate domain of v (rather with AC or SAC)if the domain evolves thenpush the variables concerned into Lif v is a state variableandif domain now equal to {1} thenpush the corresponding basevariables (if any) into Lif v is in Pibfiltrate domain of v (rather FC or SAC)if the domain evolves thenpush the variables concerned into Lend while2.3 ExampleThe example we have chosen here is the classical car configurationexample ([4], [6]) enhanced with a small structural decomposition.the whole problem contains eight variables. Four of them composethe basic requirements, whereas the last four compose the options.BasicFigure 1.Example problem : car configurationCarPackage ∈ {L, D, S}Frame ∈ {C,S H}Engine ∈ {S, M, L}Battery ∈ {S, M, L}OptionsSunroof ∈ {Sr1, Sr2}Aircond ∈ {Ac1,Ac2}Glass ∈ {T, NT}Opener ∈ {A, M}The problem is composed of eight base variables and three CPs.To encode the activity state, we need one state variable for each, soeleven state variables are required.The table 2 shows how to encode the hierarchical composition ofCPs within CPs and variables within elementary CPs. We can noticethat two approaches are available : either one n-ary constraint likeC1 or C2, or either many binary constraints like C3 to C5. the firstapproach is interesting when the constraint is very tight, the moreextreme case is ”if the CP exist then all sub CPs exist” leading totwo n-uplets all zero or all one. The second approach is more interestingwhen many sub-CPs are optional, the constraint is then veryloose (one could have coded this by an n-ary constraint containingthe forbidden valuation).Table 2.Example of problem modelizationConstraints encoding the structure relationship.C1 : Car is composed of Basic and Optionsstate(Car) state(Basic) state(Options)0 0 01 1 161

C2 : Basic is composed of Package, Frame, Engine and Batterystate(Basic) state(Package) state(Frame) state(Engine) state(Battery)0 0 0 0 01 1 1 1 01 1 1 1 1C3 Options is composed of Sunroofstate(Options) state(Sunroof)0 01 01 1C5 Options is composed of Glassstate(Options) state(Glass)0 01 01 1C4 Options is composed of Aircondstate(Options) state(Aircond)0 01 01 1C6 Options is composed of Openerstate(Options) state(Opener)0 01 01 1Constraints encoding the former Activity Constraints, expressing the forbidden values(C7 to C15 from right to left and from up to down)state(Sunroof) state(Glass)1 00 1state(Opener) state(Sunroof)1 0Package state(Aircond)L 0Frame state(Sunroof)C 1sunroof state(Opener)Sr2 0Sr1 1state(Engine) state(Battery)1 0Package state(Sunroof)L 0D 0Sunroof state(Aircond)Sr1 0Battery Engine state(Aircond)S S 1Constraints encoding the former Compatibility Constraints, expressing the forbiddenvalues (C16 to C19 from right to left and from up to down)Opener Aircond BatteryA Ac1 SA Ac1 LA Ac2 SA Ac2 MPackageSLAircondAc2Ac1PackageSSunroof Aircond GlassSr1 Ac2 TFrameCExample of an interactive configuration.1. At the beginning, and after a simple arc-consistency enforcing,Basic is active, and all the variables inside are active too. Batteryis active due to the combination of C2 and C82. The user excludes L from the domain of P ackage (P ackage ≠L), it remains two possible values for P ackage.3. The user selects P ackage ≠ S, by propagation, sunroof andGlass become active (by C10 and C7), so Options becomes active(by C3 or C5) and F rame ≠ C by C13).4. The user selects state(Aircond) ≠ 1, this is a manual exclusionof a base variable from the search space.5. The user selects F rame ≠ H, Engine ≠ S, Glass ̸= NT ,Opener ≠ A6. At this point we let a tree search algorithm complete the configurationfor us, leading to Engine ≠ L, Battery = S.Discussion Looking at step 1, we can deduce that the model couldhave been simplified suppressing C8 and the second tuple of C2.Step 3. F rame{C} has been removed by propagation, but a completepre-processing of the model (for example, using [1] we areable to compute the whole set of solutions) would have detected thatF rame{C} should be removed from the model. Thus it is possibleto reduce the problem to an equivalent one, suppressing this valuefrom the domain and the tuples using it.Step 4. Enforcing a state value is an elegant way to solve the problemof user choice over an optional variable, at this stage, Aircondcould still become active or not, the user has decided to have no airconditioner. Thanks to the representation of state through a variablethis choice is propagated the same way as classical valuations.Step 6. The user think he has expressed his needs, and do not careof the exact values that are going to be chosen for the remaining variables.A tree search algorithm is then run on the problem consistingof active not-instantiated variables (domain not restricted to a singleton),trying to extend the current valuation to a valid solution (i.e. aconfiguration) without backtracking on user choices. This feature isvery useful within configurators.3 ConclusionsThe main contribution of this paper to the configuration domain is topropose a model able to express a configurable product in a hierarchicalway which is compatible with most of the CSP algorithms. Asfar as we know, only the work reported in [5] has dealt with this hierarchicalapproach problem which is a fundamental aspect for configurationdeployment in industry.The proposed elements have been set in a software package andtests on various problems (including randomly generated ones) havebeen conducted. Time measurements on interactive configurationwith rather small models ( fifteen state variables, fourteen base variables)is under the tenth of second, deserving the title of interactive.Achieving various levels of consistency over the sub problems doesnot show, for now, significant results. In our opinion, more preciseparameters of a configuration problem (and of randomly generatedproblems) should be studied, in order to show their influence overvarious search algorithms. This is an ongoing work we will focus on,as well as adapting optimization techniques to our model.ACKNOWLEDGEMENTSWe would like to thank Access Commerce, its management and R&Dteams for their support all along this research work.REFERENCES[1] Amilhastre J. : Représentation de l’Ensemble de Solutions par Automated’Etats. Thèse de l’Université de Montpellier, (1999).[2] Dechter R., Dechter A.: Belief Maintenance in dynamic constraint networks.In proceedings of AAAI’88, (1988), pp. 37-42.[3] Ginsberg M. : Dynamic Backtracking, in Journal of Artificial IntelligenceResearch. AI Access Foundation and Morgan Kaufmann Publishers,(1993), pp. 25–46.[4] Mittal S.,Falkenhainer B.: Dynamic Constraint Satisfaction Problem. Inproceedings of the 8th AAAI conference, (1990), pp. 25-32.[5] Sabin D., Freuder E. : Configuration as Composite Constraint Satisfaction.Technical Report FS-96-03, AAAI Fall Symposium on configuration,Boston. AAAI Press (1996), pp. 28–36.[6] Sabin M., Freuder E. : Detecting and Resolving Inconsistency and Redundancyin conditional Constraint Satisfaction Problems. WorkshopAAAI’99 on configuration, Orlando. AAAI Press (1999).[7] Verfaillie G., Lobjois L. : Problèmes de satisfactions de contraintes. Revued’Intelligence Artificielle, volume 9, number 3 (1995), pp. 339–373.[8] Veron M., Fargier H., Aldanondo M. : From CSP to Configuration.Workshop AAAI’99 on configuration, Orlando. AAAI Press (1999).62

Product Data Management (PDM) SystemSupport for the Engineering Configuration Process- A Position Paper -Samir Mesihovic 1 and Johan Malmqvist 2Abstract. This position paper treats the use of a PDM systemintegrated product configurator to support development andconfiguration of highly customized product variants. The problemis investigated as a part of a Ph.D. project performed at ChalmersUniversity of Technology, Sweden.1 INTRODUCTIONDuring recent years, competition between engineering companieshas become much harder. The companies that win the competitionare those who can first deliver highly customized products thatmeet customer requirements and company constraints.PDM (Product Data Management) systems and productconfigurators are computer tools that make it possible forcompanies to shorten product development time and sales-deliveryprocess. The term sales-delivery process includes all the phasesrequired to sell, design, order, manufacture and finally deliver anindividual product to a customer [4].PDM systems keep track of the masses of data and informationrequired to design, manufacture and then support and maintainproducts during the entire product life cycle. PDM systems alsoprovide support for modelling of processes that can be executed onthe data in the system [2]. Product configurators are systems thatuse product definition information in the sales-delivery process forfast and correct configuration of working product variants thatfulfil customers’ requirements and company constraints such asproduction and delivery capabilities.The problem is that the product configurators as used in manycompanies these days, do not fully support the engineer-to-orderprocess that sometimes needs to be done in order to furthercustomize a preliminary configured product (Chapter 2.2). Thistask demands an integration between product configurator andengineering applications such as CAD/CAM/CAE.1 Department of Machine and Vehicle Design, Chalmers University of Technology,SE-412 96 Göteborg, Sweden, e-mail: samir@mvd.chalmers.se2 Department of Machine and Vehicle Design, Chalmers University of Technology,SE-412 96 Göteborg, Sweden, e-mail: joma@mvd.chalmers.seAnother problem is to update product configurators with a newrelease of product configuration data. Invalid information in theproduct configurator systems leads to incomplete and invalidproduct specifications. For this reason correct information in theproduct configurators is vital for quality and assurance. Moreover,the engineering staff that has most knowledge about the company’sproducts can often not transfer that knowledge to the company’sconfigurator because there is a lack of user-friendly methods andcomputer tools for such task..A more effective product configuration knowledge transfer fromthe product development process to the sales-delivery process andproduct configurator is needed.Different types of the product configuration concept arepresented in chapter 2. Chapter 3 gives an introduction to the PDMsystem integrated product configuration concept and an example ispresented. Finally, conclusions and recommendations for futurework are given in chapter 4.2 PRODUCT CONFIGURATIONMittal and Frayman define product configuration as a special typeof design activity, with the key feature that the artefact beingdesigned is assembled from a set of pre-designed components thatcan only be connected together in certain ways [6].Pre-designed components are re-usable, completely designed indetail and can be manufactured without any additional information[3, 4].Up to now, product configurator systems have been mostlyimplemented as commercial sales configurators, as parts of ERPsystems or as company specific developed solutions.These configurators work well for products that exclusivelyconsist of pre-designed components. However, in some cases,products consist of a mix of pre-designed, parametric andmodifiable components, e.g., speciality valves used in the processindustry.Parametric components are pre-defined to some extent, but thekey parameter values must be determined before they can bemanufactured and assembled [3].63

PRODUCT & PROCESS DEVELOPMENTMARKET ( Specification … )DESIGN ( CAD, FEM … )PRODUCTION ( CAM, Robot SIM … )SUPPLIERSPHYSICALPRODUCTPDMERPMANUFACTURINGPRODUCTPRODUCTDOKUMENTATIONPRODUCTDOKUMENTATIONDOCUMENTATIONPRODUCT CONFIGURATOR( sales & engineering)CUSTOMERREQUIREMENTS:Abstract andfunctionalknowledgeabout the product• InterpretationrulesSPECIFICATIONSPECIFICATIONMAPPINGMAPPING• Customer• Sales person• DesignerTECHNICALSPECIFICATION:Interpretedcustomer'sneeds intoa technicalproductspecificationREQUIREMENTSREFINEMENT• Customer• Sales person• Designer• Functional knowledge• Technical knowledge• Structural knowledge• Company’s abilitiesPRELIMINARYPRELIMINARY CONFIGURATIONCONFIGURATIONSET OF POSSIBLECONFIGURATIONS:Defined productvariant(s) that fulfilcustomerrequirements.• Customer• Experiences• Consultations• Price• Quality• OptimizationcriteriaSELECTION• Visualization• OptimizationPRELIMINARYCONFIGUREDPRODUCT:Fully or partiallyconfiguredproduct consisting ofpre-defined componentswith calculated criticalparameter values.• Designer• Production engineer• Supplier• Functional knowledge• Technical knowledge• Structural knowledge• Company’s abilities• Customer requirements• CAD• Visualization• Simulation• Optimization• Calculation• PDM• ERPDESIGN-TO-CONFIGURERELEASE TO PRODUCTION:Includes bill-of-material and otherproduction information requiredfor manufacturing.FINAL PRODUCT:Finalized detail designincluding theautomaticallyconfigured partof the product andthe customerspecific designed part.• Customer requirements• Technical specification• Manufacturing capabilities• Price• Delivery time• Quality• etcFINAL PRODUCTEVALUATION& ORDER• Customer• Visualization• PDM• ERPPRODUCTIONPLANNINGFigure 1 Sales-delivery process containing an automated product configuration part where the pre-designed components are identified and assembled,and an engineering part where the initially configured design is finalized. The general model of integrated product and process development is re-drawnfrom Andreassen and Hein [1]. The procedure for product configuration is an extension of Schwarze's [7] model by adding the design-to-configure step.A modifiable component has pre-defined functionality, but thedesign is not solved in detail because of the large variations incustomer demands when it comes to that part of product'sfunctionality, e.g. inlet and outlet connector design for highpressure reducing valves used in the process industry. In order todefine a modifiable component, an engineering task must be doneduring the sales-delivery process.The existing configurators provide limited support for suchproducts. For this reason, the definition of configuration, givenabove, should be extended in order to support configuration ofproducts containing pre-designed, parametric and modifiablecomponents. It follows that two product configurator types /product configuration strategies can be identified:• Assemble-to-order configurators supporting traditionalassemble-to-order process.• Engineer-to-order configurators supporting engineer-toorderprocess.2.1 Assemble-to-orderAssemble-to-order configurators have standard configurationabilities presented by Mittal and Frayman. They give strongsupport for the assemble-to-order process but have limitedcapabilities for supporting the engineer-to-order process. Productconfiguration models [4] used in the assemble-to-orderconfigurators are typically built after the product developmentprocess and are based on a fixed number of components and rulesfor their assembly. That results in a fixed number of productvariants that can be offered to the customers (computers, mostautomobiles). The product structure generated during the productconfiguration process often can not be modified afterwards.Furthermore, assemble-to-order configurators are often integratedwith order and manufacturing systems so that once they have beenconfigured, product variants can automatically be manufacturedand delivered. Assemble-to-order concept presented above includestypically the specification mapping step, the preliminaryconfiguration step and the selection step of the sales-delivery64

process (Figure 1). After the selection step, release to production,manufacturing and delivery can be automatically proceeded.2.2 Engineer-to-orderIn the engineer-to-order configuration concept, some parts of theproduct are pre-designed components and can be automaticallyconfigured while other components must be specially designedaccording to customer requirements (transformers, specialityvalves, elevators). The automated part of the engineer-to-orderprocess can use standard assemble-to-order configurationapproach. The engineering part of the process has to be supportedby a configurator but also by other applications, e.gCAD/CAM/CAE tools in order to assure a fully working endproduct(see Figure 1).During the automated configuration part of the engineer-toorderprocess an "open" product structure is generated. In the openproduct structure some objects are fully identified by using predesignedcomponents, including article numbers and assembled incertain way, while other objects are left unidentified and anengineering effort needs to be done in order to define this part ofthe product structure [5].The unidentified objects of the product structure are typicallyparametric and modifiable components. Parametric componentsmay be treated as pre-designed components if the parameter valuesare determined during the automated part of configuration processby using calculation applications directly integrated with theassemble-to-order configurator. However an engineering processmust be done in order to design the modifiable components. In thiscase, the configurator can deliver information concerningmodifiable components, e.g. customer requirements, componentfunction, component type, parameter data, and componenttemplate, that helps engineers to effectively design the solution.This requires support from CAD/CAM/CAE tools. Theengineering part of the engineer-to-order process is here calleddesign-to-configure (Figure 1). An important constraint for thedesign-to-configure process is that pre-designed, parametric andmodifiable components assembled in the end-product have to worktogether properly to achieve functionality according to thecustomer requirements. Furthermore, the workflow and the productconfiguration data has to be managed in order to ensure thatimportant engineering phases are followed and that the data neededis available in every step. This can be supported by using a PDMsystem. It is also important to have information about production,delivery and supplier abilities during the design-to-configureprocess. This demands an integration to the ERP system.The engineer-to-order configuration concept enables companiesto dramatically increase the number of available product variantson the market and is close to the custom engineered productconcept (prototypes), while using mass-production and assembleto-orderpossibilities for the pre-designed components. Thedifficulty is then to do this in an efficiency equal to or higher thanthat of the assemble-to-order concept. There is therefore a need tomanage the product configuration data in a more efficient wayduring the product development and the sales-delivery process.This issue is discussed in chapter 4.3 PDM INTEGRATED PRODUCTCONFIGURATION CONCEPTFrom the beginning, PDM systems were aimed at supporting alldesign engineering work, but have had weak support for productconfiguration. Improved capabilities for product configurationsupport have been introduced recently in major PDM systems suchas Windchill, eMatrix, Metaphase, IMAN [8, 9, 10, 11]. Thesesolutions give the user better facilities for developing productvariants, product configuration models and product configuratorportals in an integrated environment.PRODUCT CONFIGURATOR- System-developer interface -CreateproductconfigurationmodelCreateviews & reportsPRODUCT & PROCESS DEVELOPMENTMARKET ( Specification … )DESIGN ( CAD, FEM … )PRODUCTION ( CAM, Robot SIM … )PDMProductProductconfiguratorconfiguratorExternalapplications:• Parameter calculation• Report generation• CAD• Visualization• Parameter tables• Optimization• etc.ProductconfigurationProductvisualizationProductanalysis &evaluationPRODUCT CONFIGURATOR- End-user interface -Figure 2 PDM integrated product configurator where the PDM is usedfor management of product configuration data during the productdevelopment process and their communication to the product configurator.Furthermore it provides integration with external CAD/CAM/CAEapplications.During the product development process, the PDM system is usedto manage product data in different phases. At the same time, PDMenables concurrent development of products and productconfiguration models (Figure 2). A PDM integrated productconfigurator further provides support for version management ofproduct configuration models. It enables the user to re-use old65

product configuration models and retrieve old product variants.This is important for maintenance and delivery of spare parts. Theconfiguration logic stored in a PDM integrated productconfigurator is typically parameters, options and constraints(explicit and case tables). For simple product configuration models,there is no need of specialist programming skills. A graphicrepresentation makes the configuration modeling task easy. Formore complex products a programming effort still needs to bedone. That enables the system administrator to create moreadvanced product configuration models. It also supports integrationwith external applications such as parameter calculation programs,publishing programs, constant tables sheets, visualization tools etc.This can be important for companies which already have assembleto-orderconfigurators but need further product customizationduring the sales-to-delivery process. In this case, a PDM basedproduct configurator can first execute an external assemble-toorderconfigurator and then proceed to a customization process forthe automatically generated solution.Many of the new product variants on the market are derivedfrom existing product variants, where a part of the product is newdesigned and the rest is based on the old concept. By using a PDMintegrated product configurator, engineers can test how the newconcepts work together with old ones at an early stage. Theengineer can also generate the old product variants and study themin order to approve the new ones. Product configurators contain allproduct information needed to effectively generate product variantsthat fulfil customer requirements. That information can besubmitted to the engineer via the PDM, so that he can identify andreport the product configuration data needed for configuration ofthe new product variants.Our current work is concentrated on investigating the pros andcons of PDM integrated product configurator solutions. Theresearch method applied is based on a combination of case studiesat three Swedish engineering companies and the development ofdemonstrators in commercial PDM tool with integrated productconfigurator.As a first result, a test system for configuration of hydrauliccylinder variants has been developed. The system is based on aPDM system integrated product configurator (Windchill ProductConfigurator 4.0), a CAD system (Pro/ENGINEER) and amathematical software (MATLAB 5.3).4 CONCLUSIONS AND FUTURE WORKThere is justification for a renewed investigation of the possibilitiesof implementing support for development of the configurableproducts in PDM systems. The idea is to manage the productconfiguration data in the PDM system during the productdevelopment process in such way that it is later easy to use in thesales-delivery process for updating the company’s productconfigurator. Furthermore, it is important to support the design-toconfigureprocess where the product configuration data is neededto effectively finalize once preliminary configured productaccording to the customer requirements.Integration between PDM and ERP systems is still a bottleneckin companies, and it can lead to problems in updating PDM basedconfigurators in relation to production and supplier capability data.The expected result is planned to be a method for use of PDMtools to support management of product configuration data in theproduct development and the sales-delivery process for themechanical products containing pre-designed, parametric andmodifiable components.5 ACKNOWLEDGEMNTSThis work was financially supported by NUTEK, the SwedishNational Board forTechnical Development. Special thanks also to a Swedishengineering company, BTG Källe Inventing, that develops andmanufactures specialty valves for process industry. We would alsolike to thank people at PTC Nordic's office in Sweden for thesupport concerning Windchill and Pro/Engineer.6 REFERENCES[1] M.M. Andreassen and L. Hein, Integrated ProductDevelopment, Springer-Verlag, New York, 1987.[2] CIMdata: Product Data Management: The Definition,An Introduction to Concepts Benefits, and Terminology,CIMdata Inc., Fourth Edition, 1997.[3] J. Tiihonen, T. Soininen. T. Männistö, R. Sulonen,State-of-the-practice in product configuration - a surveyof 10 cases in the Finnish industry, IIA ResearchCentre, Helsinki University of Technology, Finland,1996.[4] J. Tiihonen, T. Soininen, Product Configurators -Information System Support for Configurable Products,TAI Research Centre and Laboratory of informationProcessing Science, Product Data Management Group,Helsinki University of Technology, Finland, 1997.[5] L. Jansson, Business Oriented Product Structures,Thesis for the Degree of Doctor of Philosophy,Department of Production Engineering, chalmersUniversity of Technology, Sweden, 1992.[6] S. Mittal, F. Frayman, Towards a generic model ofconfiguration tasks, Proceedings 11 th International jointconference on artificial intelligence, 1395-1402, USA,1989.66

[7] S. Schwarze, Specification Mapping - the integration ofcustomer requirements within a product configuration,Institute of Industrial Engineering and Management(BWI), Switzerland, Swiss Federal Institute ofTechnology (ETHZ), 1993.[8] PTC, Windchill,http://www.ptc.com/products/windchill/prodplanning/ds_factor.htm, 2000.[9] MatrixOne, eMatrix,http://www.matrixone.com/products/applications.html,2000.[10] SDRC, Metaphase, http://www.sdrc.com/nav/softwareservices/metaphase/configure.html,2000.[11] Unigraphics Solutions, iMAN,http://www.ugsolutions.com/products/iman/products/,2000.67

Conceptual Modeling of Product Familiesin Configuration ProjectsNiels Henrik Mortensen 1 , Bei Yu 2 , Hans Jørgen Skovgaard 2 and Ulf Harlou 1Abstract. During the early phases of configuration projects veryimportant decisions are made which will heavily influence theperformance of the company, benefits in different functionalareas (production, sales, purchase, product development, serviceetc), maintenance of the configuration system and quality of thedialogue between the configuration system and the users. Todaythere exists very sparse tools and procedures which can assist theearly phases, i.e. conceptual modeling of the products and productassortment. This paper presents a five-phase procedure forconceptual modeling in configuration projects. Each of the fivephases is sup ported by a set of tools. The main idea of the procedureis utilization of a so-called Product Family Master Plan,which is a formal description of the product assortment and itsvariation. The procedure has been tested at one of Baan's customerswith very convincing results.1 GROWING PRODUCT ASSORTMENTIn many companies the product assortment is growing quicklydue to an increased number of customer specific product variants.There are many “good” reasons for that, e.g.:• When a customer ison the phone and wantsa new feature included,it is difficult to say no.• No one in a companydare to cut away variants.• No one dare to say no toa great new productinvention.• Resources utilized formaintaining the productassortment is not measuredand visible.Figure 1. Complex product assortmentThe growing product assortment normally leads to an increasedturnover but not necessarily to increased profit. The reason isthat all new parts or products become tasks in all functional areasin the company. Some one has to purchase, storage, produce,market, sell, ship etc. the new variant. The company might betrapped, thus the majority of resources are spent on maintainingthe big complex product assortment and the ability to innovateand develop new product are dramatically reduced.Now one could argue that it is not difficult to see the problems,but what about the solutions? A main challenge is to master theright balance between variance and commonality. The productassortment shall show variance from a market point of view, andshow commonality from a company point of view. Variance ofthe product assortment is a relational property between the productassortment, competitor products and customers. Commonalityis a relational property that at least two products have in relationto a functional area. If e.g. two machine parts can be manufacturedby the same lathe then they posses commonality fromproduction point of view. Commonality ensures reduction ofcomplexity in all activities carried out in a company.How shall a company handle the right balance between varianceand commonality? There exist two very powerful alternatives,namely application of modularization and configuration.Modularization is a way of structuring the product assortmentand configuration is way of handling knowledge about the productassortment. Configuration and modularization can be appliedindividually or in combination. Sometimes products are not configurableand therefor modularization is a prerequisite for obtaininga product assortment, which is configurable.This paper is treating configuration – more specifically the conceptualphases in a configuration project. The next section willbriefly explain the reasons for doing conceptual modeling in aconfiguration project, and then a procedure and toolbox for conceptualmodeling will be presented. This procedure and toolboxhas been tested at one of Baan’s customers and experience fromapplication will be explained.The work is done within Baan Development, which is currentlydeveloping a new powerful language for configuration. Thisprocedure for conceptual modeling is targeted at the new configurationlanguage, [1], [6]. This modeling language from Baanwill be so flexible that an approach taking the need of the companyas starting point is possible rather than taking the staringpoint in the modeling language and tools.1 Department of Control and Engineering Design,Technical University of Denmark, Building 358, DK-2800 Lyngby,email: nhm@iks.dtu.dk2 Baan Company, Baan Nordic, Hørkær 12A, DK-2730 Herlev,email: byu@baan.com, hjskovgaard@baan.com68

2 REASONS FOR CONCEPTUAL MODELINGWhen a company has finished modeling of the product assortmentvery important decisions have been made. It is decidedwhich product variants that shall be offered to the market andthereby which products and subsystems that shall be manufactured(purchase, logistics, transport, service etc). This means thatboth turnover and costs are influenced directly by the contents ofthe configuration system. It can therefore be argued that decidingon the structure of the configuration model is a business decisionrather than a configuration technology decision. Making a constraintsmay seem innocent but may be a very crucial decision.Like in any other projects important decisions are made in theearly phases of a configuration project, i.e. the phases where themodel structure in the configuration system is decided. Experienceshows that when 10-15% of the resources are consumed80% of costs, maintainability, efficiency and effectiveness etcare disposed.Today there only exist sparse results from the early phases of aconfiguration project. Often there is a jump from specification totyping in the attributes, constraints, resources etc in the configurationsystem, see figure 2. This is an unfortunate situation becausethe domain experts, e.g. sales, production, purchase, productdevelopment have difficulties on seeing what decisions aremade and they can not react.Figure 2: Sparse results from the conceptual phasesThe main reason for developing a procedure handling conceptualmodeling is to make the early phases explicit and visible. This isexpected to improve conditions for bringing in relevantstakeholders early in the projects and improve conditions forensuring that there exists a proper leitmotif from overall businessgoals to contents of the configuration model.Another reason for developing the procedure is that it is sometimesdifficult to maintain and update a configuration modelwhen new products are introduced in the product assortment. Itcan be difficult to remember the meaning of attributes, constraints,resources and mode of action for the configuration system.Last but not least it is the intention that the conceptual modelingprocedure shall make it possible for a company to divide themodeling of production families between domain experts (purchase,production, quotation, sales, product development) and ITspecialists.To sum up there are four main reasons for developing a procedurefor conceptual modeling of product families in the Baanconfiguration system:• Support business decisions in the early phases of a configurationproject.• Improve documentation thus conditions for updating andmaintenance of the configuration system is improved.• Allow a possible labor division of modeling productfamilies between domain experts (e.g. sales, purchase,production. design, product development) and IT specialist.• Allow the starting point for modeling to be the need ofthe company rather than modeling language and tools.3 HOW TO MODEL A PRODUCTASSORTMENT?According to systems modeling [7], [8] there are two types of attributes,which are relevant when a product or product assortmentis being modeled. These attributes are named structural andbehavioral attributes. Structure is answer to the question, what isit? and behavior is answer to the question, what is it able to do?Examples on structure attributes for a car are car type, size of theengine, number of doors and color. Examples of behavioral attributesfor a car are speed, acceleration, noise-level and fuelconsumption. The distinction between structural attributes andbehavioral attributes is relevant because only the structural attributescan be determined directly during configuration. Formallyspeaking the behavioral attributes and the structural attributesare related to each other in a causal way. The identificationof structure and behavioral attributes is fundamental when modelingproducts.Another aspect that is relevant to modeling is deciding upon theoverall structure of the configuration model. A product has severalstructures, see figure 3. A product has e.g. supply, purchase,production, assembly, shipping, transport, sales, maintenanceand recycling structures.Now one could ask which of the above structures should theconfiguration model be based on? Some of the factors that willinfluence the structure are application area of the configurationsystem, frequency of application, stability of the product assortment,domain complexity. Probably there does not exist a genericanswer to determining the structure but often a functionalstructure is feasible. Seen from a front office point of view, customersare generally asking for solutions, which solve functions.Seen from a back office point of view production shall deliverparts which will be come a product with certain functionality. Afunctional structure means that each element in the model solvesfunctions. Identification of the functional structure is supportedby the functions-means tree law. This tool is described further insection 4.2.It is relevant to work with more alternative product structuresbecause one can not look at a product structure and ask is thisgood or bad. Only by comparing alternatives it is possible toevaluate and find the most suitable one.69

the possibilities for involving domain experts (sales, production,design) and company management in the crucial decisions duringmodeling in a configuration project.Figure 3 A product assortment has several structures, [5]A formal way of describing the product assortment is a so-calledProduct Family Master Plan (PFMP). A PFMA consist of twomain elements: a generic part-of structure and a generic kind-ofstructure, cf. figure 4.Figure 5: Discussing the product assortment in front of the productfamily master planThe product family master plan constitutes the core of a modelingprocedure that is the topic of the next section.4 MODELING PROCEDUREThe modeling procedure consists of five phases supported by anumber of tools. The content of each phase is further explainedin the next sub sections.• Identification of configuration task.• Identification of product family master plan.• Conceptual modeling of product family master plan.• Detailed modeling of product family master plan.• Modeling of product family in the configuration system.Figure 4: Contents of Product Family Master PlanThe generic part-of structure describes the modules, assembliesand parts that exist in all the products within the assortment orthe product family. Each element is described by attributes thatare determined during configuration. The Generic kind-of structuredescribes the modules, assemblies and parts which arechangeable in the product assortment. The product family masterplan is thereby a complete description of the product assortmentand the way variants are created.The PFMP is described on a big piece of paper typically 2 meterstimes 3 meters. Very often companies have never been ableto get an overview of the whole product assortment, see figure 5.Experience has shown that the product family master plan isvery good tool for discussing the product assortment, i.e. whereto start modeling in the configuration system, which variantsshall be included, which technologies are stable and which technologieswill change? Where does the company make money onthe variants and where does it looses money etc. Having a completeand visual descriptions of the product assortment improvesThe amount space in this paper does not allow all tools to bedescribed in details and therefore focus is put on the tools thathas been developed within Baan and Technical University ofDenmark.4.1 Identification of configuration taskThe purpose of this phase is to define what the configurationsystem must accomplish in accordance with stakeholders demandsand overall business objectives. Important questions to beanswered in this phase are: Who should benefit from applicationof the configuration system? Where to harvest the benefits?,Which activities shall be supported by the configuration system?,What are the leitmotif from creation of business to contents ofthe configuration system?The tools supporting this phase are:• Stakeholder identification• IDEF 0 – activity analysis• Scenario techniques70

• Use-cases• Life cycle analysis4.2 Identification of product family master planThe objective of this phase is to get an overview and describe theproduct assortment. The means for describing the product assortmentis the Product Family Master Plan. Important questionsthat this phase should contribute to answering: What are thevariants that the company wants to offer to the market what arethe variants that the company does not want to offer? What variantscan be expected in the future?light, focus light, change direction, see figure 8. By this principlethe function structure for a product assortment can be describehierarchically.The function means tree diagram provide an overview of alternativeways a function can be realized and is a good foundationfor discussing the existing product assortment variants and identificationof which part of the function structure that will be invariantand which parts is likely going to change.Figure 6 and 7 shows examples on working with a Product FamilyMaster Plan.Figure 6 Working on different alternative Product Family master plansFigure 8 Function means tree, based on [4]Supporting tools in this phase are:• Terminology charts• Function means tree• Product family master plan chart• Variance card• Commonality cardFigure 7 Final Product Family Master PlanThe identification of the function product structure is supportedby the so-called function means tree, see figure 8. The startingpoint is identification of the overall function of the product. Theoverall function of an overhead projector (a means) is to enlargeand project an image. This function can be carried out by differentmeans, e.g. slide projector principle, OHP principle andEpiscope principle. Each of these means requires the existenceof lower level functions, e.g. carry image, provide light, diffuse4.3 Conceptual modelingIn this phase each of the elements of the product family masterplan is described. For this phase a modeling tool has been developed[9], which is inspired by the object oriented modelingparadigm, [2] [3], see figure 9. In this modeling tool each classin the product family master plan is described a Class Description(CD) card. Below the contents of a CD card is further explained.71

Class Description CardClass name:Class number:List of aggregation classes:List of inheritance classes:Function and picture:Responsibility:Date:Status:o Workingo FinalCD-CardConstraints within the class are restrictions on how the componentsand defining parameters may be related. An example of aconstraint within a car class could be that cars sold in SouthAmerica should have an air conditioning system.Constraints to other classes are restrictions on how the classescan be related to other classes in the configuration system.Mode of action is description of the input and output parametersto the class. Input and output can be related to the user of theconfiguration system and other IT systemsDefining parameters:Components:Sources describe the reason for the contents of the CD Card. Theidea is that all defining parameters and constraints shall have areason. The reason can e.g. be a stakeholder, documents withinthe company.Constraints within the class:4.4 Detailed modelingConstraints to other classes:In this phase modeling is carried out in the same way asconceptual modeling but the configuration language usedin the configuration system is utilized. The previous phases areindependent from choice of configuration system. Main supportingtool in this phase is CR (Class Responsibility) cards,which has the same structure as class description cards.Mode of action:Sources:Figure 9: Class description cardList of aggregation classes describes part-of relations to otherclasses. Aggregation classes for a car could be engine, transmissionsystem and chassis.List of inheritance classes describes the kind-of relations to otherclasses. Inheritance classes of transportation equipment can bee.g. busses, planes and trains.Function and picture contains a short description of the functionalityof the class within the product. As en example the mainfunctions of a window is allow light to enter, allow venting andallow people to escape in case of fire etc. Picture contains asketch/picture/diagram of the class. This is relevant for decidingon a consistent product terminology. When e.g. geometry is involvedthis can be utilized for determining coordinate systemconventions, governing parameters etc.Defining parameters are the attributes that can be determineddirectly during configuration.Components are elements, which the class consists of. For a carcomponents might be sunroof, stereo and air-condition which aretypically boolean and not further defined.4.5 Modeling by means of configuration languageIn this phase the model is build up and tested within the configurationsystem. It is possible to divide the modeling between domainexperts and IT experts. It means that identification of configurationtask, identification of product family master plan,conceptual modeling are carried out by domain experts and detailedmodeling and modeling in the configuration system couldbe carried out by IT specialists if desired based on the ClassDescription cards and Class Responsibility Cards.5 EXPERIENCE FROM APPLICATIONThe modeling procedure has been tested in one company. Thecase company is developing, manufacturing and selling buildingequipment. Approximately 5.000 people are employed in thecompany, which produces 4.500.000 products pr. year. In orderto stay competitive the company has to be able to deliver customizedproducts to the end users. The intention is to be able todeliver more than 300.000 variants seen from a customer pointof view. Currently the products are not configurable, due tocomplex plastic components that are not changeable. Therefor aso-called fulfillment project has been initiated in which 150 peopleare working. Approximately 25 people are working on theconfiguration part of the project.The family master plan in this case was drawn on a big piece ofpaper approximately 4 meters times 2 meters. It was placed inthe center of the project room where the 150 people were working,thus the majority of people working on the project had topass the product family master plan on the way to their desks, tomeetings etc.During the project, this family master plan was important forcreating dialogue with many kinds of stakeholders. Three alternativefamily master plans were developed during the projects. It72

seems important to carry out alternatives because there does notexist one correct product family master plan. The different alternativeswill lead to configuration systems that possess differentperformance, maintainability and flexibility to bring in newproducts in the assortment. The most important consequence ofutilization of the product family master plan is that it is bringinga concept phase into a configuration project, thus the familymaster plan is visible and it is possible for stakeholders to reacton the contents before modeling in the configuration systemstarts.Reactions from this company are:• "I like the naming convention that you have usedthroughout your documentation"• "It is crucial to have an unequivocal naming conventionand way of describing things"• "The way of visualizing the product family master planwas beneficial and provided an overview of the productassortment that we did not have before"• "Your sketches in the Class Description cards togetherwith the product family master plan are GOOD"• "Your documentation does not tell how the configurationmodel is maintained, but it is the foundation forbeing able to maintain the model. If these documentsdoes not exist we can not maintain the configurationmodel"• "If you had not introduced the Product Family MasterPlan I doubt that we would have realized the commonaltiesbetween the product families"• "It is difficult for us to forget the Bill Of Material. It isnice to see that the models are built up from function,functional units, assemblies and parts because we makedecisions about these"• "It sound like the Product family master plan and theClass description cards is great for getting our thoughtsdown"• "We consider using this procedure for the Back OfficeConfiguration too"• "We need to train people in the very important thinkingpattern that is behind this procedure"• "The people who fill out the CR cards must have detailedknowledge about the product, manufacturing,market and some basic understanding of object orientedmodeling"• "This is the only procedure that I have seen for documentingthe configuration model"• "I like the product family master plan, because we canbring in relevant stakeholder earlier on"stakeholders earlier on and have “facts” based dialogue concerningvariance and commonality of the product assortment.The Class Description Cards ensure documentation and traceabilityof a configuration model. Preliminary experiences showsthat is it possible to divide the modeling task between domainexperts and IT specialists, thus that modeling in the configurationsystem can be carried out based on the contents of the ClassDescription Cards.Further work on the conceptual modeling procedure involvesapplication in two Baan configuration projects. The next step forthe modeling procedure is development of a Baan course onconceptual modeling that will be launched together with the newBaan configuration language and tools. The goal of this coursewill be to train people in companies, thus they are able to modelthe product assortment by means of the modeling tools.REFERENCES[1] Baan, Baan CAVA Concept guide [Confidential], BaanCompany, Herlev 2000[2] Coad, P & Yourdon, E: Object oriented analysis, secondedition: Prentice Hall, New Jersey 1991.[3] Coad, P & Yourdon, E: Object oriented design, second edition:Prentice Hall, New Jersey 1991[4] Hubka, V. & Eder, W.E.: Theory of Technical Systems,Springer-Verlag. Berlin, 1988.[5] Andreasen, M.M., Hansen, C.T. & Mortensen, N.H.: Thestructuring of Products and Product Programmes, Proceedingof the 2’nd WDK Workshop on Product Structuring, June 3-41996, Delft University of Technology, Delft, The Netherlands,1996.[6] Yu, Bei and Skovgaard, Hans Jørgen, A Configuration Tool toIncrease Product competitiveness. IEEE Intelligent Systemsand Their applications. July/August 1998.[7] Haberfellner, R et al: Systems Engineering, Verlag IndustrielleOrganisation, Zürich, 1995[8] Klir, J. & Valach, M.: Cybernetic Modelling, Iliffe Books,London, 1965.[9] Nielsen, M.P. & Harlou, U.: Modelling Product Families InConfiguration Systems, M.Sc.-thesis, Department of Controland Engineering Design, Technical University of Denmark,1999.[10] Mortensen, N.H.: Design Modelling in a Designer'sWorkbench - Contribution to a Design Language, Ph.D. thesis,Department of Control and Engineering Design, TechnicalUniversity of Denmark, Lyngby 1999.6 CONCLUSIONSIt is very clear that handling the conceptual phase of a configurationproject is crucial for the success. It is often difficult tohandle the conceptual phases because the knowledge by definitionis vague. Application of the proposed procedure based onthe Product Family Master Plan is formalizing the modelingactivities in the early phases and proposes a visual way of working.The implication of this is that it is possible to involve73

¡SAT-Based Consistency Checking of AutomotiveElectronic Product DataCarsten Sinz and Andreas Kaiser and Wolfgang KüchlinAbstract. Complex products such as motor vehicles or computersneed to be configured as part of the sales process [3, 8]. If thesale is electronic, then the configuration and some validity checkingof the order must be done electronically as part of an electronicproduct data management system (EPDMS). The EPDMS typicallymaintains a data base of sales options and parts together with a setof logical constraints expressing valid combinations of sales optionsand their transformation into manufacturable products. Due to thecomplexity of these constraints, creation and maintenance of the configurationdata base is a nontrivial task and error-prone. We presentour system BIS which is commercially used to check global consistencyassertions about the product data base used by the EPDMS ofa major car and truck manufacturer. The EPDMS uses Boolean logicto encode the constraints, and BIS translates the consistency assertionsinto problems which it solves using a propositional satisfiabilitychecker. We expect our approach to be especially suited for rapidlychanging complex products as they increasingly appear in electroniccommerce.1 IntroductionWe present our system BIS, an extension to a commercially usedelectronic product data management system (EPDMS) at Daimler-Chrysler AG, the manufacturer of the Mercedes lines of passengercars and commercial vehicles. BIS is just now beginning commercialservice to weed out residual defects in the product data base thatis used by the main EPDMS for order checking and production planning.The EPDMS uses Boolean logic to encode the manufacturabilityconstraints, and BIS translates global consistency assertions onthe constraints into problems which it solves using a propositionalsatisfiability checker. BIS is programmed in modern object-orientedclient/server technology and easily runs on a current laptop.The automotive industry today manages to supply customers withhighly individualized products at low prices by configuring each vehicleindividually from a very large set of possible options. E.g., theMercedes C-class of passenger cars knows far more than a thousandoptions, and on the average more than 30,000 cars will be manufacturedbefore an order is repeated identically. Heavy commercialtrucks are even more individualized, and every truck configuration isbuilt only very few times on average.Traditionally, a sales person will bespeak the individual order withthe customer. Still, the space of possible variations is so great thatthe validity of each order needs to be checked electronically againsta product data base which encodes the constraints governing legalSymbolic Computation Group, WSI for Computer Science, University ofTübingen and Steinbeis Technology Transfer Center OIT, Sand 13, 72076Tübingen, Germany, HTTP://WWW-SR.INFORMATIK.UNI-TUEBINGEN.DEcombinations of options (e.g., no two radios; no steel sun-roof forconvertibles). But the maintenance of a data base with thousands oflogical rules is error-prone in itself, especially since it is under constantchange due to the phasing in and out of models. Every faultin the data base may lead to a valid order rejected, or an invalid(non constructible) order accepted which may ultimately result inthe assembly line to be stopped. Therefore, an EPDMS is employedto maintain the product data base and check orders.DaimlerChrysler AG, for their Mercedes lines of cars and commercialtrucks, employ a mainframe-based EPDMS which does thevalidity checking of each individual order (followed by initial productionplanning) in an off-line process. It also supports the on-linemaintenance of the product data base by the staff of the product documentationdepartment. The data base contains a large number ofconstraints formulated in Boolean logic. Some of the constraints representgeneral rules about valid combinations of sales options, otherformulae are attached to parts and express the exact condition underwhich each part is needed for an order to be manufactured. Basedon some years of experience with the current EPDMS, it was foundthat it is not humanly possible to keep such a large and constantlychanging data base of logical rules and formulae absolutely defectfreewithout help from an automated reasoning system for the documentationlogic.Therefore our system BIS was created as an extension to the currentEPDMS to help the product documentation staff in proving complexglobal consistency assertions about the data base. As an example,BIS can check for each of the thousands of sales options whetherit can legally be contained in at least one valid (manufacturable) order.BIS can also deal with partially specified orders, checking e.g.which engine options are still valid given the preselected body andinterior, or it can check which parts cannot possibly be part of anyvehicles that go to a certain country.While the current EPDMS is used off-line, it is clear that somethingsimilar must be used on-line in an electronic sales system foreven simple configurable products, and a system like BIS is thenneeded to keep the product data base defect free. In an electronicmarket, there is no more knowledgeable sales-person to assist thecustomer and to prevent silly orders, and it may not even be feasibleto contact the customer personally to sort out problems once an orderis submitted. Hence we argue that the methods used in BIS todaywill be useful in electronic markets with even much simpler productstomorrow.In Section 2, we shall now summarize, from [7], the capabilitiesof the core BIS system (BIS 1.0). In Section 3 we shall presentsome modifications and extensions that went into the current BIS 2.0,based on feedback from actual industrial use of BIS 1.0 on commercialproduct documentation data.74

WUV¢2 BIS: A SAT-Based Consistency Checker forProduct DocumentationBefore turning to the description of the BIS system, we will need togive a rough picture of the underlying EPDM System which it complements.Then we present some consistency criteria that can be examinedusing the BIS system, and show how they translate into SATinstances. Thereafter we will shortly comment on the architecture ofour system.2.1 DaimlerChrysler’s EPDM System DIALOGIn the following we will describe the EPDM system used for DaimlerChrysler’sMercedes lines more thoroughly.A customer’s order consists of a basic model class selection togetherwith a set of further equipment codes describing additionalfeatures. Each equipment code is represented by a Boolean variable,and choosing some piece of equipment is reflected by setting the correspondingvariable to true. As model classes can be decoded into aset of special equipment codes, all rules in the product documentationare formulated on the basis of codes.Slightly simplified, each order is processed in three major steps,as is depicted in Figure 1:1. Order completion: Supplement the customer’s order by additional(implied) codes.2. Constructibility check: Are all constraints on constructible modelsfulfilled by this order?3. Parts list generation: Transform the (possibly supplemented) orderinto a parts list.All of these steps are controlled by logical rules of the EPDMS. Therules are formulated in pure propositional logic using AND, OR andNOT as connectives, with additional restrictions placed on the rulesdepending on the processing step, as will be shown below.Constructibility CheckIn general, constructibility of a customer’s order is checked accordingto the following scheme: For each code, there may be severalrules indicating restrictions under which this code may be used. Acode is called constructible (or valid) within a given order if all constrainingrules associated with this code are fulfilled, i.e. all of theserules evaluate to true. For an order to be constructible (or valid), eachcode of the order must be valid. The constructibility check consistsof two different parts: The first one is independent of the car modelclass considered, while the second one takes into account additionalfeatures of each car model class. Although the latter incorporates anadditional hierarchical organization of rules, we will not elaborate onthis. For our purpose the constructibility rules may be considered ina unified, simpler form:dhìbjXkYg[l\_mnfwhere d is a code and XkYg[]\ m an arbitrary formula. Such a rule expressesthe fact that whenever code d occurs in a customer’s order,the order must fulfill condition XZYD[]\ m , i.e. XZYD[]\ m must evaluate totrue for this order.Parts List GenerationThe parts list is subdivided into modules, positions and variants, withdecreasing generality from modules to variants. Parts are grouped inmodules depending on functional and geometrical aspects. Each positioncontains all those parts which may be used alternatively in oneplace. The mutually exclusive parts of a position are specified usingvariants. Each variant is assigned a formula called a code rule and apart number. A parts list entry is selected for an order if its code ruleevaluates to true. Thus, to construct the parts list for a completed andchecked customer’s order, one scans through all modules, positions,and variants, and selects those parts which possess a matching coderule.2.2 Consistency of Product Documentation ¨ ¥ !¨¨Figure 1.Order CompletionProcessing a customer’s order.'-, .0/-1+2 345¨6 718¥6 9¨5¨6;:¨?=-@Ä B-@DC$Ë F¨FG =H=¨B+I =-@ J0K-L+M NOPQ RLS¥Q T¨P¨Q"$#¨%¨%¨&'('¨)+*£¥¤ ¦¨§¨¤ ©¨¤ ¨ The order completion (or supplementing) process adds implied codesto an order. The process is guided by special formulae associatedwith each code, which are of the following form:XZYD[]\_^a`cbedgfwhere d is a code (i.e. a propositional variable) and XZYD[]\ ^ an arbitraryformula. The semantics of such a rule is that whenXZYD[]\ ^conditionevaluates to true under an order, then code is added to thatorder. Thus, each rule application extends the order by exactly onecode, and the whole completion process is iterated until no furtherdchanges result. Ideally, the relationship between original and augmentedorder should be functional. However, the result of the ordercompletion process may depend critically on the ordering of rule application.We have shown in [7] how to identify potential instancesof this problem.Due to the complexity of the product documentation occurring inthe automotive industry, some erroneous rules in the data base arealmost unavoidable and usually quite hard to find. Moreover, the rulebase changes frequently, and rules often introduce interdependenciesbetween codes which at a first sight seem not to be related at all.As the rule base not only reflects the knowledge of engineers, butalso world wide legal, national and commercial restrictions, the complexityseems to be inherent to automotive product configuration, andis therefore hard to circumvent.A priori, i.e. without explicit knowledge of intended constraintson constructible models, the following data base consistency criteriamay be checked:Necessary codes: Are there codes which must invariably appear ineach constructible order?Inadmissible codes: Are there any codes which cannot possibly appearin any constructible order?Consistency of the order completion process: Are there any constructibleorders which are invalidated by the supplementing process?Does the outcome of the supplementing process depend onthe (probably accidental) ordering in which codes are added?Superfluous parts: Are there any parts which cannot occur in anyconstructible order?75

X‹r } ‹ € ‰Ž d ‹ ƒ XZYD[]\_m ‹ w¡¥€dAmbiguities in the parts list: Are there any orders for which mutuallyexclusive parts are simultaneously selected?Note that the aforementioned criteria are not checked on the basisof existing (or virtual) orders, but constitute intrinsic properties ofthe product documentation itself.By incorporating additional knowledge on which car models canbe manufactured and which cannot, further checks may be performed.Besides requiring additional knowledge, these tests often donot possess the structural regularity of the abovementioned criteriaand thus cannot be handled as systematically as the other tests.2.3 SAT Encoding of Consistency AssertionsWe will now show how to encode the consistency criteria developedin the last section as propositional satisfiability (SAT) problems.Transformation of the consistency criteria into SAT problemsseems to be a natural choice for two reasons: first, the rules of theunderlying EPDM system are already presented in Boolean logic;and second, SAT solvers are applied in other areas of artificial intelligencewith increasing success [1, 6].The formulation of all these consistency assertions requires an integratedview of the documentation as a whole or, more precisely,a characterization of the set of orders as they appear having passedthe order completion process and the constructibility check. So wefirst concentrate on a Boolean formula describing all valid, extendedorders that may appear just before parts list generation.Let the set of order completion (supplementing) rules oqpsrtguvbefwwwf uvDxiy XZYD[]\ ^ z ìb{d z. Then the set of completelysupplemented orders is described by | formula ,¡wherewith uvDz rr |~} z € x‚ XZYD[]\_^ z„ƒ¡¥€Now, let p‡rt d v ¡ fwwwfˆd vD‰Šywith d vŒ‹ X d ‹ ìb XZYD[]\ mrd z†… wbe the set of constructibility rules. Then the set of constructible orders isdescribed by formula , whereXAfter having made a change to the documentation rule base (or,alternatively, in regular temporal intervals) some or all of the abovementionedconsistency criteria are checked, and potential flaws of thedocumentation are reported by BIS.Each inconsistency indicated by BIS has then to be analyzed andinterpreted by the product documentation experts: If the product documentationdoes not correctly reflect reality (in the sense that it doesnot properly classify what actually can be manufactured), the errorhas to be corrected – either by adapting the documentation rules orby modifying the product itself. Otherwise the reported inconsistencymost likely is an intended exceptional case that does not need anyfurther processing.Even if not all such inconsistencies are – or even can be – handled,the quality of the product documentation is nevertheless improved.This is an important fact, considering that SAT is an NP-completeproblem. Thus, it cannot be guaranteed that the system will find allinconsistencies within a suitably short amount of time. We experienced,however, that for our application worst-case behavior and unacceptablylong run-times are the rare exception; the run-times foreach proof are usually clearly below one second.2.5 Architecture of the BIS SystemThe BIS system is constructed employing object-orientedclient/server technology. It consists of a general prover moduleprogrammed in C++ with a propositional satisfiability checker asits core component; a C++ server which maintains product data inraw and pre-processed form and handles requests by building theappropriate formulae for the prover; and a graphical user interfaceprogrammed in Java, through which tests can be started and resultscan be displayed. The three components communicate via CORBAinterfaces, thereby achieving a great flexibility, allowing e.g. toplace each component on a different, suitable computer or to usemultiple instances of a component (e.g. prover), if the workloaddemands this. Figure 2 shows a schematic view of the BIS systemarchitecture.Moreover, the set of all orders that have passed the supplementingprocess and the constructibility control are described by ‘ , where£¢ þ¥ÿ¡¤¦¥¨§¦©£¡¦¦£Ü¥ÝŸÞ$ßàÊˆË Ì†Í†Î$ËÏX•wWe now have reached our goal to generate a propositional formulareflecting the state before parts list generation. The mapping of theconsistency criteria to SAT instances is now straightforward. For example,code is inadmissible, iff ‘–“ is unsatisfiable. The othercriteria are converted accordingly, but some of them require a moresophisticated translation, especially those tests concerning the orderdcompletion process. The complete set of transformations from ourconsistency assertions to SAT instances – as they are actually builtinto the BIS system – can be found in [7].Finally, it should be noted that the process described here is simplifiedin comparison to the actual order processing that takes placein the DIALOG system. The general ideas should nevertheless be apparent.2.4 Integration into Work-FlowWe will now briefly describe how the BIS system is integrated intothe existing product documentation process.á¥âŸã$ä0åæ¥çŸè$éˆê¥§¦©¨+ª ¡n¢¤£«+¬_­g®¯­±°ÄÅÇÆȈÉFigure 2.˜ —˜š›†œŸž$íî0ï$ðñòŒóô óëˆìõŒö÷ŸøùúÇûüˆýÀ¨Á¸Â_Â_à ²l³¯´¨µ_³_´]¸·c¹»º¯·c¼½³§¼±¾+¿BIS system architecture.ÐˆÑ Ò†Ó†Ô$Ñ0ÕÖˆ× Ø†Ù†Ú$׈ÛWithin the server, the UserLayer is responsible for authenticationand handles user requests by starting the appropriate consistencytests. Therefore it employs the TestLayer which in turn is responsiblefor managing (i.e. scheduling, starting) all consistency checks.The data layer is used as a mediator between the TestLayer and theEPDM system, and supports caching of pre-computed data.‘’} r~|”“76

XXd3 Extensions Based on ExperienceSince the first evaluation deployment of the BIS 1.0 system (and evenbefore), we have received a lot of feedback from DIALOG users atDaimlerChrysler. This helped us greatly in improving the system invarious aspects. We will now describe relevant user feedback as wellas experience-induced changes in greater detail.Restricting the Set of Valid OrdersThe formalization mentioned above allows the analysis of the set ofall valid orders. However, as it turned out, it is often necessary torestrict the set of orders to be considered to some subset of all validorders. This may be needed, for example, to check assertions aboutall valid orders of a certain country, or about all valid orders with aspecial motor variant.The formalization of order restrictions could easily be realized byadding a formula p describing the additional restriction to the constructibilityformula ‘ , and running the tests on ‘ “„p .Figure 3.BIS system client.Valid Additional Equipment OptionsNot only for an individual order, but also for a whole class of orders,it may be interesting to know what kind of additional equipment maybe selected without making the order invalid. This can be used on theone hand to analyze the product data, but may also serve a customerto find possible extensions of a partially specified order. This canbe achieved as follows: Using the restriction possibility of the lastparagraph, the partially specified order serves as p a restriction onthe set of valid orders to be considered. Then it is checked for allcodes whether or not the ‘ “ p “formula is satisfiable. If thisis the case, then code is a valid extension of the partially specifiedorder.d dThe following items appeared to be indispensable for a broad everydayuse:Push-button technology: The logical prover component can becompletely hidden from the user, and it needs no assistance infinding a proof. Interaction with the prover is done in terms familiarto the operating personnel.Graphical user interface: The BIS system offers an elaboratedgraphical user interface, as can be seen from Figure 3. No crypticcommand lines have to be typed by the user.Short response times of the system: As BIS 1.0 was used moreand more interactively, consistency checks had to exhibit short andpredictable run-times. We will describe below in more detail howwe could achieve this.Customized special checks: Although we offered a generalpurposeinterface to the prover 2 which could be used to performa lot of non-standard consistency checks on the product documentation,acceptance of this tool was rather poor. Thus, weimplemented a set of further customized special checks andextended the client accordingly.3.1 Additional FunctionalityWe will now report on functional extensions that went into BIS 2.0.As we already mentioned above, most of these additional tests couldin principle have been performed with the general-purpose test facilityof BIS 1.0, but required some kind of – frequently almost trivial –logical problem encoding by the user; an interpretation of the resultreported by the client; and often an annoying manual generation of aseries of tests.This interface allowed queries about the existence of valid orders with specialproperties, where the demanded property is an arbitrary propositionalformula.Combinations of CodesUpon creation and maintenance of parts list entries, the followingquestion frequently has to be answered: Given a fixed set of codes,which combinations of these codes may possibly occur in a valid order?The answer to this question decides over which parts list entrieshave to be documented and which have not.Performing this kind of test one by one for each combination manuallyappears to be rather cumbersome. An automatic generation ofall possible combinations seems to be more appropriate. Again, thiscan be simply realized by generating systematically all combinationsone after the other and checking the corresponding formulae for satisfiability.Groups of CodesAlthough not reflected by the documentation structure, we found itcharacteristic for automotive product data that certain codes are symmetricallyrelated. We call a set of codes symmetrically related(with respect to a rule-based product documentation) if there is anon-empty subset X of those rules containing at least one code of setp, such p that is invariant under all permutations of the codes of set.A typical case for a set of symmetrically related codes is a setof mutually exclusive codes, where one of the codes must appear ineach valid order, i.e. each order must contain exactly one code of theset. For example, in the DIALOG documentation system each ordermust contain exactly one code that determines the country in whichthe customer has ordered the car.Since these kinds of symmetric relations can not be explicitlystated in the EPDM system, but are implicitly given by several rulesformed with the binary connectives NOT, AND and OR, we addeda possibility to check for a given list of codes (a group of codes)whether or not each valid order contains exactly one of these codes.77

[xxrtrfThis is realized by checking the satisfiability of formula ‘ that describesall valid orders, extended by the additional constraint that theorder contains none or at least two of the codes specified in the group.3.2 Extending the Propositional LanguageWhile sets of mutually exclusive codes represent the most prominentexample for a symmetrical relation, one can also think of situationswhere other symmetrical relations are applicable. For example,a customer can choose exactly one of a set of audio systems or he cancompletely dispense with audio systems. This means he can chooseat most one of a set of options. Another example is a valid order thatneeds exactly of a set of colors specified. Obviously giving thesekinds of restrictions in standard propositional logic leads to excessivegrowth in formula size which is certainly unacceptable [ for userinteraction, and may even in the simplest case exhaust the availableresources. The fact that the mutual exclusiveness of country codesin DaimlerChrysler’s current product documentation is not explicitlystated underlines this.To address this drawback we added – as is described in detailin [5] – the abovementioned expressions to standard propositionallanguage. This extends the language by expressions of the formfwŒwwff f!, where pkf #"Zf #$kf #% y, is a positivep”} ¡¡ fwwwfnumber and are arbitrary formulae of the extended language.The semantics of such an expression p is that exactly of theformulae are true. Thus, the fact that at most one of three possible&(' and should appear in an order corresponds &audio systems & ¡ fto the expression*)which is equivalent to writing}+& ¡ f f&(' && ¡ “/& “ ,0- & ¡ “1& ' “ ,.- & “/& ',.-in pure propositional logic.A closer analysis even shows that any formula in standard propositionallogic can be transformed to an equivalent formula based solelyon the additional connectives, which differs in size from the originalformula only by a constant factor. Thus, these connectives provideus with a method to represent formulae for automotive product datamanagement in a compact, structure-preserving and uniform way.As a consequence of introducing additional connectives, we refrainfrom conversion to clausal normal form (CNF) for satisfiabilitychecking – in contrast to most of the commonly used Davis-Putnamstylepropositional theorem provers [2]. Although this step involvesa more complex prover implementation using a tree data structure(as opposed to integer arrays for CNF representation), its benefit isbeyond the mere compactification of formula representation. On formulaegenerated from automotive product data our prover showedin most cases similar or better performance. Moreover, we avoidedan additional data structure to represent the CNF of the formula andtherefore could reduce the complexity of the overall system as wellas the space requirements and improve response time, because CNFconversion of very large formulae is non-trivial.Even beyond consistency checking, we consider the introductionof a logical connective that reflects symmetrical relations to be essentialto efficiently document product data on the basis of Booleanconstraints (see also [9]).4 Conclusion and Future WorkWe presented BIS, a system to complement DaimlerChrysler’s automotiveEPDM system DIALOG. BIS serves as a tool to increase thequality of the product documentation by allowing to check certainglobal consistency conditions of the documentation data base as awhole. In BIS 2.0, the consistency assertions and the product documentationrules are translated to formulae of an extended languageof propositional logic, which additionally includes a connective forsymmetric relations.Feedback from the documentation personnel showed us which features– among others – should be preferably included into a supporttool for product documentation: ease of use via a graphical user interface;good integration into existing work-flow; push-button technology;and short response times.Although current satisfiability checkers are quite advanced andSAT is still – and increasingly – an area of active research [4], wecould learn from the special applicational needs how to improvepropositional SAT tools and how to optimize prover techniques. Specialconstructs occurring frequently in product documentation, suchas selection of one out of a set of [ entities, are usually not appropriatelysupported by generic Boolean SAT checkers. Therefore, we seehere a wide area of adaptations and improvements on prover technologyand possibly further speed gains, brought forward by applicationalneeds.For the future, we assume a system like BIS to be indispensable forelectronic sales over the World Wide Web. Complex products need tobe configured and checked electronically in large numbers, and thusthe presence of a correct electronic product documentation receivesincreased attention. But electronic product documentation shows upto be complex and rapidly changing, thus making maintenance ofthe product data base difficult. Electronic business may increase thespeed of product changes as well as the complexity of products, asproduct cycles and life times are likely to shrink down. Moreover,the needs of customers may vary considerably around the globe, thusforcing a diversification of the product palette.Additionally, as we move towards fully electronic sales, configurationand on-line validity checking of even simple products may berequired to be aided by electronic support systems in the future, andthere will probably be no supporting human sales person. Such systemsheavily depend on the quality of electronic product data, whichwe try to improve with our techniques.REFERENCES[1] A. Biere, A. Cimatti, E. Clarke, and Y. Zhu, ‘Symbolic model checkingwithout BDDs’, in Tools and Algorithms for the Analysis and Constructionof Systems (TACAS’99), number 1579 in LNCS. Springer-Verlag,(1999).[2] M. Davis and H. Putnam, ‘A computing procedure for quantification theory’,in Journal of the ACM, volume 7, pp. 201–215, (1960).[3] F. Freuder, ‘The role of configuration knowledge in the business process’,IEEE Intelligent Systems, 13(4), 29–31, (July/August 1998).[4] I. Gent and T. Walsh, ‘Satisfiability in the year 2000’, J. Automated Reasoning,24(1–2), 1–3, (February 2000).[5] A. Kaiser. Saturation-based satisfiability checking without CNF conversion,2000. (unpublished manuscript).[6] H. Kautz and B. Selman, ‘Planning as satisfiability’, in Proceedings ofthe 10th European Conference on Artificial Intelligence (ECAI’92), pp.359–363. John Wiley and Sons, (1992).[7] W. Küchlin and C. Sinz, ‘Proving consistency assertions for automotiveproduct data management’, J. Automated Reasoning, 24(1–2), 145–163,(February 2000).[8] J. McDermott, ‘A rule-based configurer of computer systems’, ArtificialIntelligence, 19(1), 39–88, (1982).[9] T. Soininen and I. Niemelä, ‘Developing a declarative rule language forapplications in product configuration’, in Practical Aspects of DeclarativeLanguages, First International Workshop (PADL’99), number 1551in LNCS, pp. 305–319. Springer-Verlag, (1999).78

Unified Configuration Knowledge Representation UsingWeight Constraint RulesTimo Soininen ½ and Ilkka Niemelä ¾ and Juha Tiihonen ½ and Reijo Sulonen ½Abstract. In this paper we present an approach to formally definingdifferent conceptualizations of configuration knowledge, modelingconfiguration knowledge, and implementing the configurationtask on the basis of the formalization. The approach is based on aweight constraint rule language and its efficient implementation designedfor representing different aspects of configuration knowledgeuniformly and compactly. The use of the language to represent configurationknowledge is demonstrated through formalizing a unifiedconfiguration ontology. The language allows a compact and simpleformalization. The complexity of the configuration task defined bythe formalization is shown to be NP-complete.1 IntroductionProduct configuration can be roughly defined as the task of producinga specification of a product individual, a configuration, from aset of predefined component types while taking into account a setof restrictions on combining the component types. Knowledge basedsystems for configuration tasks, product configurators, have recentlybecome an important application of artificial intelligence techniquesfor companies selling products tailored to customer needs.Several approaches to configuration are based on relatively wellunderstoodgeneral formalisms, such as constraint satisfaction, its extensions,and variants of description logics. Other approaches havedefined specific configuration domain oriented conceptual foundations.These include the three main conceptualizations of configurationknowledge as resource balancing, product structure and connectionswithin a product [11]. Despite the research, there are fewformal models of configuration aiming to unify the different formaland conceptual approaches. Such models are needed to facilitate rigorousanalysis and comparison of the different approaches.In this paper we present an approach that facilitates formal representationof configuration knowledge based on different and unifiedconceptualizations. In contrast to many previous approaches thathave developed special purpose algorithms for each conceptualization,our aim is to provide for fast prototyping of conceptualizationsand configuration tasks based on them. This is accomplished by capturingthe configuration knowledge using a neutral representationlanguage called weight constraint rules and implementing the configurationtask using a general implementation of such rules. Therefore,when changing the configuration model or its underlying conceptualfoundation, only the representation of the knowledge is changed.½ Helsinki University of Technology, TAI Research Center and Lab. of InformationProcessing Science, P.O.Box 9555, FIN-02015 HUT, Finland,email: Timo.Soininen,Juha.Tiihonen,Reijo.Sulonen@hut.fi¾ Helsinki University of Technology, Dept. of Computer Science and Eng.,Lab. for Theoretical Computer Science, P.O.Box 5400, FIN-02015 HUT,Finland, email: Ilkka.Niemela@hut.fiThere is no need to design a new algorithm for the configuration task,as the general implementation of the rule language can still be used.We first briefly introduce the logic program like rule language thathas been specifically designed to allow representing knowledge ondifferent aspects of configuration in a uniform and simple manner.At the same time, the computational efficiency of the configurationtask has also been taken into account. The language has a declarativesemantics providing a formal definition for the product configurationtask. The semantics captures the property that a configuration canonly contain elements that are justified by the configuration model.This property has been identified as important in e.g. the research ondynamic constraint satisfaction problems (DCSP) [5]. The justificationproperty also allows a more compact and modular representationof knowledge than e.g. classical logic or constraint satisfaction problems[10, 9]. For example, a subset of the rule language can represente.g. CSP and DCSP in a simple, compact manner [10]. It also extendsthese approaches with cardinality and weight constraints.After introducing the rule language we demonstrate its applicabilityto configuration knowledge representation. This is done by showinghow a configuration model represented using a simplification of ageneralized configuration ontology [11] covering product structures,resource balancing, connections and constraints is mapped to a set ofrules. The rules are not used by product modelers but as an intermediatelanguage that a higher level configuration modeling languageis translated to. Due to the built-in justification property of the language,the mapping is modular and relatively simple. Extending therepresentation to cover a more complex conceptualization is straightforward,although we discuss in brief some challenges to this. Therelevant decision problem for the configuration task is defined andshown to be NP-complete on the basis of the mapping to rules. Finally,we discuss our approach in relation to previous similar work.2 Weight Constraint RulesIn this section we briefly introduce the weight constraint rule languageused for formalizing configuration knowledge (for more informationon the language see [7, 8]). The language extends logicprograms by offering support for expressing choices as well as cardinalityand resource constraints that are often useful in configuration:Example 1. A (partial) configuration model of a simplified PC couldconsist of the following knowledge: There is a known set of differenttypes of IDE hard disks, IDE CD ROMs, scanners and SCSI cardsthat can be parts of a PC. The different IDE hard disks and IDE CDROMs are IDE devices. A PC must have from one to two IDE devices,of which at least one must be an IDE hard disk. In addition, adesktop publishing PC must have a scanner, which can be a flatbed ora slide scanner. As the slide scanner is a SCSI device, including it in79

a configuration requires a SCSI card. There are two different types ofSCSI cards to select from. Furthermore, each component has an associatedprice. The customer might require that the total price, summedover the components in a configuration, must be less than $900.The rule language aims to capture the type of configuration knowledgein the example in a compact form. To do this, it is equippedwith conditional literals restricted by domain predicates for representingthe different types of components and other objects and theknowledge on them, such as the IDE devices above. Cardinality constraintsare introduced for representing choices with lower and upperbounds, such as for the IDE devices in the above example. Resourceconstraints on a configuration exemplified by the prices of the componentsabove are captured in the generalized language using weightconstraints, which give the language its name.First we consider ground rules, i.e., rules where variables quantifyingover a rule are not allowed. Then we introduce rules withvariables. A weight constraint rule ¼ ½ Ò (1)is built from weight constraints of formÄ ½ Û ½ Ò Û ÒÒÓØ Ò·½ Û Ò·½ÒÓØ Ñ Û ÑÍ (2)where Ä and Í are two numbers giving the lower and upper boundfor the constraint, each is an atomic formula and each Û a numbergiving the weight for the corresponding literal (an atom or its negation).Such a rule is intuitively read as follows: if the body, i.e. each of ½ to Ò, holds then the head ¼ must also hold. The semantics forsuch rules is given in terms of models that are sets of ground atoms.We say that a positive literal is satisfied by a model Ë if ¾ Ë anda negative literal ÒÓØ is satisfied if ¾ Ë. A weight constraint issatisfied by a model Ë if the sum of weights of the literals satisfiedby Ë is between the bounds Ä and Í. Note that ”” could also besimilarly used in a constraint. E.g.,¿¼ ÔÖØ´Ô ½ ½µ½¼ ÔÖØ´Ô ½ ¾µ¾¼ÔÖØ´Ô ½ ¿µ¿¼ ÔÖØ´Ô ½ µ¿¼ ¼is satisfied by a model ÔÖØ´Ô ½ ½µ ÔÖØ´Ô ½ ¾µ for whichthe sum of the weights is ½¼ · ¾¼ ¿¼ but not by a modelÔÖØ´Ô ½ ¿µÔÖØ´Ô ½ µ for which the sum is 60.We use shorthands for some special cases of weight constraints. Acardinality constraint where all weights are 1 is written asÄ ½ Ò ÒÓØ Ò·½ÒÓØ Ñ Í (3)and a cardinality constraint ½Ð½ with one literal and 1 as bothbounds simply as a literal Ð. We call rules where all constraints are literals normal rules. We can also write mixed rules such as½ ÔÖØ´Ô ½× ½µ ÔÖØ´Ô ½× ¾µ ½ ÔÖØ´Ô ½ ××Òµ (4)The semantics of a set of rules is captured by a subclass of modelscalled stable models. They fulfill two important properties: (i) a stablemodel satisfies the rules and (ii) is justified by the rules. A rule Öof form (1) is satisfied by a model Ë iff Ë satisfies ¼ at least wheneverit satisfies each of ½ Ò. A rule without a head is satisfiedif at least one of the body constraints is not. The technical details ofthe justifiability property can be found in [7], but we explain the basicintuition through an example. Consider rule (4). It is satisfied, e.g.,by the model ÔÖØ´Ô ½× ½µ. However, this model is not justifiedby the rule since there is no reason to include the head of the rule inthe model, since the body of the rule, ÔÖØ´Ô ½××Òµ, is not justified.Indeed, for the rule (4) the only stable model is the empty setwhich also satisfies the rule. Suppose we add two rules½ ÔÖØ´Ô ½ ×ÒµÔÖØ´Ô ½ ××Òµ ¾ ØÔ´Ô ½µ (5)ØÔ´Ô ½µ (6)to (4). Then each stable model of the rules (4–6) contains the atomØÔ´Ô ½µ and at least one of ÔÖØ´Ô ½ ×ÒµÔÖØ´Ô ½ ××Òµ.This holds because ØÔ´Ô ½µ is justified by rule (6) and, hence, achoice from ÔÖØ´Ô ½ ×ÒµÔÖØ´Ô ½ ××Òµ is justified by(5). If ÔÖØ´Ô ½ ××Òµ is taken, then by (4) the choice betweenÔÖØ´Ô ½× ½µÔÖØ´Ô ½× ¾µ is justified. So this implies thatØÔ´Ô ½µÔÖØ´Ô ½ ×ÒµÔÖØ´Ô ½××ÒµÔÖØ´Ô ½× ½µ isone stable model for the rules (4–6) but this not the case for theset ØÔ´Ô ½µ ÔÖØ´Ô ½ ×ÒµÔÖØ´Ô ½× ½µ as ÔÖØ´Ô ½× ½µis not justified. We note that there is an important difference betweena rule with and a rule without a head: only the former can bring somethinginto a stable model. The latter only exclude stable models.For applications it is very useful to provide rules where variablesquantifying over the whole rule can be used. With the help of variablesone can write rules in a compact and structured way and thisfacilitates developing, updating and maintaining a rule set.The semantics for rules with variables [7] is obtained by consideringthe ground instantiation of the rules with respect to their Herbranduniverse, i.e. all variable-free (ground) terms that can be builtfrom the constants and functions in the rules. However, in this generalcase the rule language is highly undecidable. A decidable subclassof rules with variables is obtained by considering the function-freeand domain-restricted case [7]. Here the intuition is that each variablehas a domain predicate which provides the domain over whichthe variable ranges. Domain predicates can be defined using normalrules starting from basic facts. Hence, it is possible to define newdomain predicates from already defined ones using union, intersection,complement, join, and projection. As an example, consider twosets of ground facts ´ µ and ´ µ giving theavailable IDE hard disks and IDE CD ROMs, respectively. Now both and can be used as domain predicates. We can also definea new domain predicate as their union using the two rules´µ ´µ ´µ ´µwhere the variable quantifies universally over a rule. Note that weuse ”;” as a separator of rules. We use the convention that variablesstart with a capital and constants with a lower case letter. A rule isdomain-restricted if every variable in it appears in a domain predicatein the body of the rule. E.g., the rule½ ÔÖØ´ ½µÔÖØ´ ѵ ¾ Ô´µ (7)is domain-restricted if Ô´µ is a domain predicate. A simple way ofunderstanding the semantics of the rules with variables is to see themas shorthands for sets of ground rules. For example, rule (7) can beunderstood as a set of ground rules of form½ ÔÖØ´Ô ½µÔÖØ´Ô Ñµ ¾ Ô´Ô µ (8)where is replaced by each constant Ô for which Ô´Ô µ holds.In order to compactly represent sets of literals in constraints conditionalliterals, i.e., expressions such as ÔÖØ´ µ ´µ canbe used in place of literals. Thus, rule (7) can be expressed as½ ÔÖØ´ µ ´µ ¾ Ô´µ (9)A rule with conditional literals is domain-restricted if each variablein it appears in a positive domain predicate in body or the conditionalpart (like ´µ above) of some conditional literal in the rule.When using conditional literals we need to distinguish betweenlocal and global variables in a rule. The idea is that global variablesquantify universally over the whole rule but the scope of a local variableis a single conditional literal. We do not introduce any notationto make the distinction explicit but use the following convention: avariable is local to a conditional literal if it appears only in this literalin the rule and all other variables are global to the rule. For example,80

in the rule (9) the variable is local to the conditional literal in thehead but is a global variable. Again a rule with conditional literalscan be understood as a shorthand for a set of ground rules resultingfrom a two step process. First all global variables are replaced by allground terms satisfying the domain predicates in every possible way.This gives a set of rules where variables appear only as local variablesin conditional literals. For example, for the rule (9) eliminationof the global variable leads to a set of rules of the form½ ÔÖØ´Ô µ´µ ¾ Ô´Ô µ (10)one for each ground term Ô for which Ô´Ô µ holds. In the secondstep, for each such rule, local variables are eliminated by replacingeach conditional literal by a sequence of ground instancesof the main predicate such that domain predicate in the conditionalpart holds. For example, in rule (10) the conditional literalÔÖØ´Ô µ ´µ is replaced by a sequenceÔÖØ´Ô ½µÔÖØ´Ô Ñµwhere the ground terms ½ Ñ are the only terms for which´ µ holds. Hence, the rule (9) can been seen as a shorthand for aset of ground rules of the form (8). Conjunctions of formÔÖØ´È µ Ô´È µ´µare also allowed in conditional parts, corresponding to a sequence ofground facts ÔÖØ´Ô µ for which both Ô´Ô µ and ´ µ hold.Domain predicates such as Ó×Ø´ µ giving the unique cost of each component can also be used for defining weights: ¼¼ ÔÖØ´ µÓ×Ø´µ Ô´µ (11)is a shorthand for a set of ground rules containing a rule ¼¼ ÔÖØ´Ô ½µ ½ ÔÖØ´Ô Òµ Ò Ô´Ô µfor each Ô s.t. Ô´Ô µ holds and where ´ ½ ½µ ´ Ò Òµ arethe only pairs for which the domain predicate Ó×Ø´ µ holds.Example 2. Consider Example 1. Using the rule language the configurationmodel can be represented in the following way. Basic componenttypes are given as corresponding facts and normal rules definingdomain predicates as for . The rule (9) captures the requirementthat a PC has from one to two IDE devices and a ruleÔÖØ´ µ ´µ ¼ Ô´µthe property that at least one of them is an IDE hard disk. The requirementsfor the scanners and SCSI cards are captured using rules(4–5) and the constraint on the total price of the components can bestated using a rule like (11).An implementation of the weight constraint rule language calledSmodels is publicly available at http://www.tcs.hut.fi/Software/smodels/. It computes stable models of domainrestrictedrules using a precompilation technique and a Davis-Putnam like procedure which employs efficient search space pruningtechniques and a powerful dynamic application-independent searchheuristic. The current implementation supports only non-recursivedefinitions of domain predicates for efficiency, and integer weightsin order to avoid complications due to finite precision of standardreal number arithmetic. Smodels is competitive even against specialpurpose systems, e.g., in planning and satisfiability problems [6].3 Configuration KnowledgeIn this section we show how to represent configuration knowledgeusing the rule language. We distinguish between the rules givingontological definitions and the rules representing a configurationmodel. The former are not changed when defining a new configurationmodel and are enclosed in a box in the following. The latterappear only in the examples. We further make the convention thatthe domain predicates are typeset normally whereas other predicatesdefining the configuration are typeset in ÓÐ.The representation is based on a simplified version of a generalconfiguration ontology [11]. In the ontology, there are three maincategories of knowledge: configuration model knowledge, requirementsknowledge and configuration solution knowledge. Configurationmodel knowledge specifies the entities that can appear in a configurationand the rules on how the entities can be combined. In ourapproach, it is represented as a set of rules. Configuration solutionknowledge specifies a configuration, defined in our approach as astable model of the set of rules in the configuration model. Requirementsknowledge specifies the requirements on a configuration andis defined as a set of rules that a configuration must satisfy.3.1 Types, Individuals and TaxonomyMost approaches to configuration distinguish between types and individuals,often called classes and instances. Types in a configurationmodel define intensionally the properties, such as parts, of their individualsthat can appear in a configuration. In the simplified ontology,a configuration model includes the following disjoint sets: componenttypes, resource types, port types and constraints. The types areorganized in a taxonomy or class hierarchy where a subtype inheritsthe properties of its supertypes in the usual manner. For simplicity weonly allow individuals of concrete, i.e. leaf, types of the taxonomy,which unambiguously describe the product, in a configuration.Individuals of concrete port and component types are naturallyrepresented as object constants with unique names. This allows severalindividuals of the same type in a configuration. Types are representedby unary domain predicates ranging over their individuals.Since a resource of a given type need not be distinguished as an individual,there is exactly one individual of each concrete resource type.The individuals that are included in a configuration are representedby the unary predicate Ò´µ ranging over individuals.The type predicates are used as the conditional parts of literals torestrict the applicability of the rules to individuals of the type only.This facilitates defining properties of individuals (see below). Thetype hierarchy is represented using rules stating that the individualsof the subtype are also individuals of the supertype. This effectsmonotonic inheritance of the property definitions.Example 3. A computer is represented by component type Ô (PC),which is a subtype of ÑÔ, the generic component type. For eachindividual Ô of component type Ô in a configuration it holds thatÔ´Ô µ. Component type (IDE device) is also a subtype of ÑÔ.A type representing IDE hard disks, , is a subtype of . Actualhard disks are represented as subtypes of , namely and .IDE CD ROM devices and are subtypes of type , whichis a subtype of . Software packages are represented by type ×Û.Software package types ×Û and ×Û are subtypes of ×Û. Port andresource types are introduced in the following sections. The followingrules define the component types and their taxonomy:ÑÔ´µ Ô´µÑÔ´µ ´µ ´µ ´µ ´µ ´µ ´µ ´µ ´µ ´µÑÔ´µ ×Û´µ ×Û´µ ×Û ´µ ´µ ´µ×Û´µ ×Û ´µ ´µ ´µ81

3.2 Compositional StructureThe decomposition of a product to its parts, referred to as compositionalstructure, is an important part of configuration knowledge. Acomponent type defines its direct parts through a set of part definitions.A part definition specifies a part name, aset of possible parttypes and a cardinality. The part name identifies the role in whicha component individual is a part of another. The possible part typesindicate the component types whose component individuals are allowedin the part role. The cardinality, an integer range, defines howmany component individuals must occur as parts in the part role.For simplicity, we assume that there is exactly one independentcomponent type, referred to as root component type. An individualof this type serves as the root of the product structure. In a configurationthere is exactly one individual of the root type. Componenttypes are also for simplicity assumed to be exclusive meaning that acomponent individual is part of at most one component individual.Further, no component type can have itself or any of its super- orsubtypes as a possible part type in any of its part definitions or thepart definitions of its possible part types, and so on recursively. Thisimplies that a component individual is not directly or transitively apart of itself. These restrictions are placed to prevent counterintuitivestructures of physical products. In effect the compositional structureof a configuration forms a tree of component individuals, and eachcomponent individual in a configuration is in the tree.The fact that a component individual has as a part another componentindividual with a given part name is represented by the tertiarypredicate Ô ´µ on the whole component individual, the part componentindividual and the part name. A part name is represented as anobject constant and the set of part names in a configuration model arecaptured using the domain predicate ÔÒ´µ.A part definition is represented as a rule that employs a cardinalityconstraint in the head. The individuals of possible part types in agiven part definition of a given component type are represented usinga domain predicate ÔÔ. It is defined as the union of the individualsof the possible component types.Example 4. The root component type Ô has as its parts 1 to 2 massstorageunits (with part name Ñ×) of type , and 0 to 10 optionalsoftware packages (with part name ×ÛÔ) of type ×Û. Note that usingan abstract (non-leaf) type, such as , in a part definition effectivelyenables a choice from its concrete subtypes. The fact that Ô is theroot component type and the part names and possible part types ofPC are represented as follows:ÖÓÓØ´µ Ô´µ ÔÔ´ ½ ¾Ñ×µ Ô´ ½µ´ ¾µÔÒ´Ñ×µ ÔÔ´ ½ ¾×ÛÔµ Ô´ ½µ×Û´ ¾µÔÒ´×ÛÔµ The part definitions for the mass storage and software packageroles are represented as follows:½ Ô ´ ½ ¾Ñ×µÔÔ´ ½ ¾Ñ×µ ¾ Ò´ ½µÔ´ ½µ¼ Ô ´ ½ ¾×ÛÔµÔÔ´ ½ ¾×ÛÔµ ½¼ Ò´ ½µÔ´ ½µThe ontological definitions that exactly one individual of the roottype is in a configuration, and that other component individuals arein a configuration if they are parts of something are given as follows:½ Ò´µ ÖÓÓØ´µ ½ Ò´ ¾µ Ô ´ ½ ¾Æµ ÑÔ´ ½µÑÔ´ ¾µ ÔҴƵThe exclusivity of component individuals is captured by the followingontological definition that a component individual can not bea part of more than one component individual: ÑÔ´ ¾µ ¾ Ô ´ ½ ¾ÆµÑÔ´ ½µÔҴƵ3.3 ResourcesThe resource concept is useful in configuration for modeling the productionand use of some more or less abstract entity, such as poweror disk space. Some component individuals produce resources andother component individuals use them. The amount produced mustbe greater than or equal to the amount used.A component type specifies the resource types and amounts itsindividuals produce and use by production definitions and use definitions.Each production or use definition specifies a resource typeand a magnitude. The magnitude specifies how much of the resourcetype component individuals produce or use.A resource type is represented as a domain predicate. Only oneresource individual with the same name as the type is needed, since aresource is not a countable entity. A production and a use definitionof a component type is represented using a tertiary domain predicateÔÖ´µ on component individuals of the producing or using componenttype, individual of the produced or used resource type and themagnitude. Use is represented as negative magnitude.Example 5. Disk space is used by the software packages and producedby hard disks. Disk space is represented by resource type ×.Each subtype of type ×Û uses a fixed amount of disk space, representedby their use definitions: ×Û uses 400MB and ×Û 600 MB.Hard disks of type produce 700MB and of type 1500MBof ×. The following rules represent the × resource type and theproduction and use definition of component types:ÔÖ´ × ¼¼µ ×Û ´µ Ö״ʵ ״ʵÔÖ´ × ¼¼µ ×Û ´µ ×´×µ ÔÖ´ × ½¼¼µ ´µ ÔÖ´ × ¼¼µ ´µThe production and use of a resource type by the component individualsis represented as weights of the predicate Ò´µ. The ontologicaldefinition that the resource use must be satisfied by the productionis expressed with a weight constraint rule stating that the sum of theproduced and used amounts must be greater than or equal to zero:Ö״ʵ Ò´µ ÔÖ´ Ê Åµ Å ¼3.4 Ports and ConnectionsIn addition to hierarchical decomposition, it is often necessary tomodel connections or compatibility between component individuals.A port type is a definition of a connection interface. A port individualrepresents a ”place” in a component individual where at most oneother port individual can be connected. A port type has a compatibilitydefinition that defines a set of port types whose port individualscan be connected to port individuals of the port type.A component type specifies its connection possibilities by portdefinitions. A port definition specifies a port name, a port type andconnection constraints. Port individuals of the same component individualcannot be connected to each other. For simplicity, we consideronly a limited connection constraint specifying whether a connectionto a port individual is obligatory or optional. Effectively an obligatoryconnection sets a requirement for the existence of and connectionwith a port of a compatible component individual.Port types are represented as domain predicates and port individualsas uniquely named object constants. Compatibility of port typesis represented as the binary domain predicate Ñ´µ on port individualsof compatible port types and a rule that any two compatible portindividuals can be connected. The connections are represented as thesymmetric, irreflexive binary predicate Ò´µ on two port individuals.82

A port individual is connected to at most one other port individual.The following rules represent these ontological definitions:¼ Ò´È ½È ¾µ ½ Ò´È ½µ Ò´È ¾µÑ´È ½È ¾µÒ´È ¾È ½µ Ò´È ½È ¾µÔÖØ´È ½µÔÖØ´È ¾µÔÖØ´È ½µ ¾ Ò´È ½È ¾µÔÖØ´È ¾µ ÔÖØ´È ½µ Ò´È ½È ½µExample 6. The configuration model includes port types and that are subtypes of the general port type ÔÖØ. These types representthe computer and peripheral device sides of IDE connection.The compatibility definition of states that it is compatible with . Correspondingly states compatibility with . The followingrules represent the port types and compatibility definitions:ÔÖØ´È µ ´È µ Ñ´È ½È ¾µ ´È ½µ ´È ¾µÔÖØ´È µ ´È µ Ñ´È ½È ¾µ ´È ½µ ´È ¾µA port definition of a component type is represented as a rule verysimilar to a part definition, but with the tertiary predicate ÔÓ signifyingthat a component individual has a port individual with a givenport name. The ÔÓÒ predicate captures the port names.Example 7. Component type Ô has two ports with names ½ and ¾ of type for connecting IDE devices. Component type has one port of type , called Ô, for connecting the device to acomputer. The Ô port has a connection constraint that connectionto that port is obligatory. In rule form:ÔÓÒ´ ½µ ÔÓÒ´ ¾µ ÔÓÒ´ Ôµ ½ Ô Ó´ È ½µ ´È µ ½½ Ô Ó´ È ¾µ ´È µ ½½ Ô Ó´ È Ôµ ´È µ ½ Ò´µÔ´µ Ò´µÔ´µ Ò´µ´µ ´µ ´È ½µ Ô Ó´ È ½ Ôµ Ò´È ½È ¾µÔÖØ´È ¾µ ¼The ontological definitions that a port individual is in a configurationif some component individual has it and that port individuals of onecomponent individual cannot be connected are also needed:Ò´È µ ÑÔ´µÔÓҴƵÔÖØ´È µ Ô Ó´ È Æµ ÑÔ´µÔÓÒ´Æ ½µÔÖØ´È ½µ Ô Ó´ È ½Æ ½µÔÓÒ´Æ ¾µÔÖØ´È ¾µ Ô Ó´ È ¾Æ ¾µ Ò´È ½È ¾µ3.5 ConstraintsAll approaches to configuration have some kinds of constraints asa mechanism for defining the conditions that a correct configurationmust satisfy. Rules without heads are used for this in our approach.Example 8. In the PC configuration model, there is a constraint thata hard disk of type must be part of È: Ô´È ½µ Ô ´ ½ ¾Æµ´ ¾µÔҴƵ ¼4 Computational ComplexityWe make the following assumptions. A configuration model Årepresented according to the ontology is translated to a set of rulesÅ as in Section 3, including the rules for ontological definitions.Then, a set of ground facts Ë is added, providing the individuals thatcan be in a configuration. Ë is constructed out of the domain predicatesrepresenting the concrete types in Å and unique object constantsfor the individuals of concrete types. The set of rules Å Ëis all that is needed for representing the product, and subsequentlyconfiguring it. The requirements are represented using another set ofrules Ê.The set Ë can be thought of as a storage of individuals from whicha configuration is to be constructed. The set Ë thus induces an upperbound on the size of a configuration. This is important since if sucha bound cannot be given, the configurations could in principle be arbitrarilylarge, even infinite. However, for any configuration modelÅ agreeing with the ontology in Section 3, a finite, bounded setÑÜ ´Åµ containing the maximum number of individuals of anyconcrete type can be shown to exist. It can be constructed using thefollowing observations. For each concrete resource type there is exactlyone individual. Every concrete component individual is a nodein the maximal compositional structure tree rooted at the unique rootcomponent individual. The tree can be constructed by going throughthe part definitions starting from the root component type. Finally,the number of port individuals is bounded by the number of componentindividuals. Now, a set Ë defining enough individuals for anycorrect configuration w.r.t. Å can be constructed by adding a factØ´ µ for each individual in ÑÜ ´Åµ whose concrete typeis Ø.We further make the assumption that the number of variables inthe rule representation of each constraint in Å and each rule in Êis bounded by some constant Ð . This is based on the observation thateven checking whether a constraint rule or requirement rule of arbitrarylength is satisfied by a configuration is computationally veryhard. This would be contrary to the intuition that checking whethera constraint or requirement is in effect in a configuration should beeasy. Since the ontological definitions in Å have at most five variables,this assumption implies that there is a bound ÑÜ´ Ð µon the number of variables in any rule of any Å and Ê.The above assumptions lead to the following definition of the decisionversion of the configuration task:Definition 9. CONFIGURATION TASK(D): Given a configurationmodel Å translated to a set of rules Å, a set of ground facts Ë,and a set of rules Ê, where the number of variables in any rule ofÅ and Ê is bounded by a constant , is there a configuration , astable model of Å Ë, such that satisfies Ê?Theorem 4.1. CONFIGURATION TASK(D) is NP-complete in thesize of Å Ë Ê.Proof. (Sketch) Task is in NP: For CONFIGURATION TASK(D)there is the following polynomial time non-deterministic algorithm:1. Guess a configuration . It holds that is of polynomial size w.r.t.Å Ë Ê since is a subset of the Herbrand Base (À )ofÅ Ë and À is at most polynomial w.r.t. Å Ë. Thelatter holds since the number of variables in any rule of Å Ëis bounded by and the size of the Herbrand Universe of Å isbounded by Å Ë.2. Check that is a stable model of Å Ë. This is accomplishedby instantiating Å Ë with its Herbrand Universe, thus obtainingthe set of ground rules ´Å ˵ , and checking that isa stable model of ´Å ˵ . Since the number of variables inany rule of Å Ë is bounded by and the size of the HerbrandUniverse of Å is bounded by Å Ë, ´Å ˵ is polynomial w.r.t. Å Ë and the instantiation can also becomputed in polynomial time. Checking if is a stable model ofa set of instantiated rules can be done in polynomial time [7].3. Check that satisfies Ê. This can be accomplished in polynomialtime similarly as in Step 2 by instantiating ÊË with its HerbrandUniverse and checking that satisfies ´Ê ˵ .NP-hardness: The NP-complete 3-SAT problem of whether apropositional sentence ´Ð ½ Ð ¾ Ð ¿µ ´Ð Ñ ¾ Ð Ñ ½ Рѵ83

is satisfiable can be reduced to the configuration task e.g. as follows:Introduce in Å a root component type Ö and add a distinct componenttype for each variable that appears in the sentence. Add to Ö apart definition for each variable such that the component type is thesame as the variable, and the cardinality is ¼ ½℄. For each clause´Ð ½ Ð ¾ Ð ¿µ, introduce the constraint rule Ø´Ð ½µØ´Ð ¾µØ´Ð ¿µ,where Ø´Ð µ ÒÓØ Ò´µÚ ´µ if Ð is a positive literal andØ´Ð µÒ´µÚ ´µ if Ð is a negative literal, where Ú is the variablein Ð . Finally, construct Ë by including a fact Ö´Ö ½µ and thefacts Ú ´Ú ½µ for each variable Ú . Now, the sentence is satisfiableiff there is a configuration of Å and Ë satisfying Ê .5 Previous WorkThere are several approaches that define a configuration oriented language,a mapping to an underlying language, and implement the configurationtask using an implementation of the underlying language.Our approach differs from these in the following respects. The underlyinglanguages do not always have a clear declarative semanticsor their implementations are incomplete. They were usually not designedfor configuration typical knowledge representation. Finally,the complexity of the configuration task has not been precisely classified.The last issue holds also for the approaches discussed next.Some exceptions to the above pattern exist. In [1], a formal definitionof configuration as constructing a Herbrand model of a descriptionlogic-like language is given. Another approach defining (implicitly)configurations as models of a language is described in [4], wherea component and connection based ontology is formalized using Ontolingua.In [1], the ontological foundation of configuration is notexplored, whereas in [4] the ontology is more restricted than ours.The approach with perhaps the most similar goals to ours is describedin [2, 3]. A similar configuration domain oriented conceptualizationand a configuration model are given a formal semantics usinga restricted variant of predicate logic extended with set constructs[2]. This definition is then mapped to a generative constraint satisfactionproblem (GCSP), and implemented using its implementation. Inour approach, the formalization is done directly using the languagethat provides the implementation. In contrast to our approach, theconfiguration task is cast as the task of finding a subset minimal setof sentences representing the configuration such that the union ofthe configuration model and the configuration together with requirementsis consistent. The subset minimality condition is a strongerform of justification than ours based on a fixpoint definition [7].The mapping from the conceptualization to the formalization in[2] is more complex than in our approach. This is partially due to amore complex conceptualization, but there are also other significantdifferences. First, unlike in [2], our mapping is modular in the sensethat each type, property definition and constraint can be formalizedindependently of other things in the configuration model. The structureof the product is represented in [2] using ports and connections,which leads to more complexity. Furthermore, defining the configurationas a stable Herbrand model eliminates the need for ”closure”axioms required in [3, 2] to restrict the set of sentences correspondingto a configuration to be complete and not to contain extraneousthings. In addition, the weight constraints allow a compact representationof things which require complex predicates in [2].It is relatively easy to extend our representation to cover a morecomplex conceptualization such as those in [11, 2]. These includeadditional concepts for representing attributes and functionality andadditional definitions for the concepts. However, some aspects cannotbe captured in a straightforward manner. E.g., the implementationdoes not yet include arithmetic for reals which is useful for expressing,e.g., attribute values and resource amounts. However, integerarithmetic is included as built-in functions.6 Conclusions and Future WorkWe have presented an approach to formally defining different conceptualizationsof configuration knowledge, modeling configurationknowledge, and implementing the configuration task on the basis ofthe formalization. The approach is based on a novel weight constraintrule language designed for representing different aspects of configurationknowledge uniformly and in a straightforward manner. Usingthe language to represent different aspects of configuration knowledgeis demonstrated through formalizing a unified configuration ontology.The language allows a compact and simple formalization.The complexity of the configuration task defined by the formalizationis shown to be NP-complete.However, the language does not allow real number arithmetic. Extendingthe implementation with these and further aspects of configurationand formalizing a more extensive configuration ontology areimportant subjects of further work. In addition, the computationalcomplexity of different possible conceptualizations should be furtheranalyzed, and the implementation performance should be tested.AcknowledgementsHelsinki Graduate School in Computer Science and Engineering hasfunded the work of the first author, Technology Development CentreFinland the work of the first and third authors, and Academy ofFinland (Project 43963) the work of the second author.REFERENCES[1] M. Buchheit, R. Klein, and W. Nutt, ‘Constructive problem solving: Amodel construction approach towards configuration’, Technical MemoTM-95-01, DFKI, (1995).[2] A. Felfernig, G. Friedrich, and D. Jannach, ‘Uml as domain specific languagefor the construction of knowledge based configurations systems’,in Proc. of 11th Int. Conf. on Softw. Eng. and Knowl. Eng., (1999).[3] G. Friedrich and M. Stumptner, ‘Consistency-based configuration’, inConfiguration. AAAI Technical Report WS-99-05, pp. 35–40, (1999).[4] T.R. Gruber and R. Olsen, ‘The configuration design ontologies andthe vt elevator domain theory’, Human-Computer Studies, 44, 569–598,(1996).[5] S. Mittal and B. Falkenhainer, ‘Dynamic constraint satisfaction problems’,in Proc. of the 8th Nat. Conf. on AI (AAAI90), pp. 25–32, (1990).[6] I. Niemelä, ‘Logic programming with stable model semantics as a constraintprogramming paradigm’, Annals of Mathematics and ArtificialIntelligence, 25, 241–273, (1999).[7] I. Niemelä, P. Simons, and T. Soininen, ‘Stable model semantics ofweight constraint rules’, in Proc. of the Fifth Intern. Conf. on LogicProgramming and Nonmonotonic Reasoning, pp. 317–331, (1999).[8] P. Simons, ‘Extending the stable model semantics with more expressiverules’, in Proc. of the Fifth Intern. Conf. on Logic Programming andNonmonotonic Reasoning, pp. 305–316, (1999).[9] T. Soininen, E. Gelle, and I. Niemelä, ‘A fixpoint definition of dynamicconstraint satisfaction’, in Proc. of the 5th International Conf. on Principlesand Practice of Constraint Programming, pp. 419–433, (1999).[10] T. Soininen and I. Niemelä, ‘Developing a declarative rule language forapplications in product configuration’, in Proc. of the First Int. Workshopon Practical Aspects of Declarative Languages, pp. 305–319,(1999).[11] T. Soininen, J. Tiihonen, T. Männistö, and R. Sulonen, ‘Towards a generalontology of configuration’, AI EDAM, 12, 357–372, (1998).84

46517)8)9;:=8>?A@CBEDGFIHKJMLONQPGRSLOTUTWVYXQZ[H\BYT]DGFYT^_PGN>ÌaKT)ZbNdceIB=f_H\BYgN>^_DGH\Z$XQah)NdBYeIg>iYPjX;DGHKN>BIJ)k.lOFYT$N>^YDGHKZ$XQa\HmDCnoNdc0XEh)NdBYe=gdiYPjX;DGH\NdBAH\JfYTWeIBITpfAL'HmDGFPGT)Jq^rT)hWD6DGNsXdB¥N>^YDGHKZ[HKtpX;DGH\NdBcuiYBIhWDGHKN>BvkxwyB¥N>^_DGHmzFINpL”HmD0h)XdBS`rTMiYJqTpf6DGNH\Z[^YaKT)Z[T)B„D'fYT‘cœXdiYamD0FYN>J|Dy^YPGNQe=aKT)J)k-Ÿ &Yx M¡0¢ Ÿ !‡ - žH\fYTpf6HKB DGN]DGFYPGT)T3hWa–XQJqJqT)J)¾h)N>B_e=gdiYPjXQDGHKNdBIJyXQPGT]fYHK¦° ² ´h)N>B_e=gdiYPjXQDGHKNdBIJOJGX;DGH\J|c–n$h)N>BYJ|DqPjXdHKB„DGJONdc+DGFYT0h)NdBYeIg>iYPjX;DGHKN>B¿¤ÀHKJyL'H\f_T)amnPGT)JqTpX;PGh‘FYTpflOFIT3h)NdBYeIg>iYPjX;DGHKN>BEZ$XdBIXdgdT)Z[T)B„D'^YPGNdÌaKT)ẐHKTWLˆNQc0DGFYT6eIT)a\fvk.ÆNdJ|D[Ndc0DGFITXdBIfÄ»Åd½O^YPGT)JqT)B„DGJX‚PGT)hWT)B„DUN;¦§TWPG¦TWÇ+NdPqDF=XQJ`rT)T)B[T‘VY^rTWB=fYT)fUN>B[e=BIfYHKBIg3¦dXdaKH\f$XdB=fUJqiYHmDjXdÌaKTyh)N>B_e=gQzJqN]HmD'F=XQJxXQDxaKTpXQJ|DyN>BIT0Z[HKBIHKZ$Xda=TWa\TWZ[T)B„Dpk„…oTyJGXpn[DGFIXQDODGFYHKJOZ[HKBYzH\J‰XdB€N>^_DGH\Z$XQa§hWN>BYeIg>i_PjXQDGHKN>Bvk1@CD HKJ ^rN>JqJqHKỲa\T[DGFIXQDHKZ$XQa.TWa\TWZ[T)B„DDGFYTWPGTHKJMZ[NQPGT‰DGFIXdB·N>BIT‰N>^_DGH\Z$XQa©h)N>B_e=gdiYPjXQDGHKNdB†HmcDGFYT‰cuiYBIhWDGHKNdB£¢¥¤§¦©¨ L'FITWPGT UXdBIf¡[XQPGTyeIV_Tpfh)NdBIJ|DjXQB DGJXdBIfLT)HKg>F„DOaKT)JqJ§DGF=XdB¡HKJ.DGFYTxB_iYZ`rTWPNQc+h)N>Z[^rNdBIT)B„DGJHKBDGFITxZ[N f_T)aœk„lOFYH\J.h)NdZ[^IaKTWV_HmD‡nT)hWDGHKN>B kPGTWJqiIamDyH\J'^_PGNQ¦>T)BHKBPGiYaKTUa\XdBIgdi=XQg>T XQB=f€H\f_T)B„DGHKeITpf·DGFYTh)NdB=f_HKDGHKNdBIJ3DGF=X;D]XdaKaKN;L !'k§lOFYTx^YPGNdÌaKT)ZŠNdcIe=B=f_HKBIgMX0JqiIHmDjXdỲa\TxhWN>BYeIg>i_PjXQDGHKN>Bc’NdP.DGFIHKJ¦>TWPGJqHKN>B#¤ kK¼{HKDF=XQJN;¦§TWP$¤&%'&†f_HKJ|DGH\BYhWD‰JqNdc’DCLxX;PGTS^=XQh‘RdXdgdT)J‰DGFIXQD¡£¢¥¤§¦ ¤©¨¤£ ¢¥¤ "!$#%'&)(+* ,.-0/1-32 §Z[HKtpXQDGHKN>B{cuiIBYhWDGHKN>BSHKZ[^rNdJqT)JyXJ|DqPGHKhWD}^IXQPqDGH\Xda~NdPjf_TWPyN>BDGFYTMJqTWDyNdcXQJqJqHKg>BIJ'DGFIT}JGXdZ[T3¦dXdaKiIT}DGNZ$XdB„n$h)N>B_e=gdiYPjXQDGHKNdBIJ)kwûh)N>B_e=gdiYPjXQDGHKNdB¤J|n_J|DGT)ZüF=XdJSDGNý`rT†T‘þ[h)HKT)B„DEHmcHmDEHKJSDGNý`rTXdaKah)N>B_e=gdiYPjXQDGHKNdBIJMNQcOX$h)N>B_e=gdiYPjXQDGHKNdB€Z[N f_T)aXdBIf‚Nd^YDGHKZ$Xdaƒh)N>B_ze=gdiYPjXQDGHKNdBIJOX;PGTyDGFYT'Z[H\BYHKZ$XdaITWa\TWZ[T)B„DGJ.NQc~DGFYHKJ.PGT)a\X;DGH\NdB~k„…†T0XQB=X;ziYJqTpfHKBS^_PjXdhWDGHKh)T>kY…oT f_TWe=BYT3XUh)a\XdJqJ0NdcN>^_DGHKZ[H\t)XQDGHKN>Bc’iIBYhWDGHKN>BIJ)“BIXdZ[T)amn¨j©Qªr¨ ²u¸ µcuiYBIhWDGHKN>BYJ)“©cuNQP[L'FIHKh‘FsDGFYTN>^_DGHKZ[H\t)XQDGHKN>Bý^YPGNdỲzaKT)ZbH\J HKBs‹Œ)yŽÈHmc§DGFITUh)NdBYeIg>iYPjX;DGHKN>BoZ[N f_T)aH\J f_T)JqhWPGHK`rTpf†HKB†XXQB=f6fYTWeIBITamnYtWT}DGFIT0h)N>Z[^YiYDjXQDGHKNdB=Xda+h)NdZ[^IaKTWV_HmD‡n[NQc1DGFIT0^YPGNdÌaKT)ẐXh)a\XdJqJ]NdcOh)N>BYh)HKJqT6Nd^YDGHKZ[HKtpXQDGHKNdB€cuiYBIhWDGHKNdBIJ3cuNQP‰L'FYH\hjF€DGFYTUN>^_DGHmzc’NdPGZ$XQa\HKJqZbDGFIXQD3HKJMHKB†ÿSŽkvlOF=X;D H\J)“+LThpXQB€JqNda\¦>TDGFIT‰^YPGN>ỲaKT)ZZ[HKtpXQDGHKN>B‰^YPGNdÌaKT)ZŠHKJH\BU‹UŒ)'Žkd…†TO^YPGTWJqT)B„D.XycuNQPGZ$Xda PGiIaKTWz `=XQJqTpfLTMX;PGT}g>HK¦§TWBXQB{NQPjXdh)aKT}DGFIXQDOJqNdaK¦§T)J'X]ÿSŽ}z h)N>Z[^Ya\T‘DGT0^_PGN>ÌaKT)Z"HKBBYN;L'aKTpf_g>Ta\XdBIgdi=XQg>TxDGF=X;D§h)XdBU`rTxiYJqTpf‰DGNMTWV_^_PGT)JqJh)N>B_e=g>i_PjXQDGHKN>B[Rh)NdBIJ|DqPGiIh‘D1h)NdBIh)HKJqTNd^YDGHKZ[HKtpXQDGHKNdB c’iIBYhWDGHKN>BIJXdBIfMJqFINpLsFINpL€LOT.hpXdBL'HmDGF·X$fYTWDGT‘PGZ[H\BYHKJ|DGH\h‰lƒi_PGH\BYg$Z$XdhjFIHKBIT HKB·X6^rNdaKn_BYN>Z[H\XdaƒDGHKZ[T HmcX6h)N>BYJ|DjXdB„D3DGHKZ[T>kvlOFITh)a\XdJqJ NdcxhWN>BIhWH\JqT[Nd^YDGHKZ[HKtpXQDGHKNdB€cuiYBIhWDGHKNdBIJhWN>BIJqHKJ|DxNQc~c’iIBYhWDGHKN>BIJ.DGF=X;DxXdJqJqHKgdB{TpXQh‘F$h)NdBYeIg>iYPjX;DGHKN>B{XdB$HKB DGTWgdPjXdaiIJqHKBIg‰DGFIT}a\XQBIg>iIXdgdT>krwyJ'XhpXdJqT3J|DGiIf_n„“„LTMcuNdPGZ$XQaKH\tWT‰X]JqiIỲJqTWD'NdcDGFIT.h)N>B_e=gdiYPjXQDGHKNdB‰^_PGN>ÌaKT)Z”cuNQP1DGFIT.•MT)ỲH–XQBU—}˜03šQ›~HKB iYVMJ|n_J|DGT)ZSk…oT]fYT‘e=BIT XQB‚N>^YDGHKZ[HKtpX;DGH\NdBScuiYBIhWDGHKN>BSc’NdPMDGFYT3J|n_J|DGT)ZbXQB=fSJqFYN;L˜}NQD"XdaKah)NdBYe=gdiYPjX;DGH\NdBcuNdPGZ$XQaKH\JqZ[J"XQPGT BITWh)T)JqJGXQPGHKamn ÿSŽ}zhWN>Z[^IaKTWDGTdk_N>HKBYH\BYT)BSXQB=f$˜}HKT)Z[T)a@‡B£X¤JqNQc’DCLxXQPGT¥hWN>BYeIg>i_PjXQDGHKN>B"Z$XdB=XQg>T)Z[TWB D€^YPGNdÌaKT)ZS“3LT¥XQPGTX$» d½vTWVYXdZ[HKBITpfUDGFYT}h)NdZ[^IaKTWV_HmD‡ng>HK¦§T)B{X‰JqT‘D'Ndc©h)NdZ[^rN>BYT)B„DGJOTpXdhjF6^YPGN;¦ H–f_HKBIgUX‰fYHKJ|DGHKBIhWDcuiIBYhWDGHKN>B_zNQc§fYHmÇ+TWPGT)B„D0h)N>BYJ|DqPjXdHKB„D}D‡n_^rT)JyHKBEh)N>B„DGTWV D0NdcDGFITWHKP0h)NdBYe=gdiYPjX;DGH\NdBXdaKHmD‡nXdBIf6LOTMLOXdB„DxDGNeIB=f6Xh)N>aKaKT)hWDGHKNdBENdc1DGFYT)JqT3h)N>Z[^rNdBIT)B„DGJ)“YXDGFYT'h)N>B_e=g>i_PjXQDGHKN>B$^_PGN>ÌaKT)Z DGNMPGT)Z$XQH\B[HKB6Žk„@ DJqT)TWZ[J.DGFIXQDOZ[NdJ|DNQcDGFIT]H\B„DGTWPGTWJ|DGH\BYg{h)XdJqT)J3X;PGTÿŽ}zChWN>Z[^IaKTWDGT]JqN[LOT]L'H\aKa©BYNdDMgdHK¦§Th)N>B_e=gdiYPjXQDGHKNdB~“ƒDGFIXQD]^YPGN;¦ H\fYT)J DGFITUc’iIBYhWDGHKN>B=XQaKHKDCn†DGFIXQD LOT[LxXQB„DpklOFITyJqTWDONQcƒhWN>Z[^rN>BYT)B„DGJXQB=fDGFYT)HmPPGT)a\XQDGHKNdBIJqFIHK^YJxH\J§hpXdaKaKTpf6X$¨j©Qª=«¬1­d® ¯q°Q±œ² ©dªo³U©p´„µWk+@‡B·X‚¨G©dª ¬ƒ­d®_¯|°d±œ² ©dª ± °Q¸q¹ LOTXQPGTgdHK¦§T)B·X[h)N>B_zXQB„n‰Jq^rTWh)Hme=h'h)N>BYJqH\fYTWPjX;DGH\NdBUcuNQP§DGFYTx^YPGN>ỲaKT)Z[JH\BUŽÄHKBDGFYHKJ§^IXd^rTWPpk…oT6iIJqTX·PGiYa\T‘zCÌXdJqTpfAa\XdBYg>i=XQg>T}›DGFIXQD[HKJ[X·JqiIÌJqT‘D[NdcMXe=gdiYPjXQDGHKNdBSZ[N fYT)avXQB=fX‰JqTWDyNdc©iYJqTWP'PGTpº„iIHmPGT)Z[T)B„DGJxXQB=f6LTMLxXQB Da\XQBIg>iIXdgdT0›ŠfYTWeIBITpf¥HKB »m¼d½õk£§NdDGFÄa\XdBIgdi=XQg>T)JEX;PGT€ÌXdJqTpf¥NdBDGN‰eIB=f$X‰h)NdBYeIg>iYPjX;DGHKN>B{DGFIXQDxJGX;DGHKJ|e=T)JxDGFITyPGTpº„iIHmPGT)Z[T)B„DGJ)k @CB€»m¼>¼W½a\XQBIg>iIXdgdT]HKJ'^YPGN;¦§TWB{DGNU`rT3ÿŽ}zChWN>Z[^IaKTWDGT}H\B†»K¼"d½õkn„“QLTxTWVYXdZ[HKBIT§DGFITxh)NdBYe=gdiYPjX;DGH\NdBUZ$XdBIXdgdT)Z[T)B„Dw0JXMh)XdJqT'J|DGi=fkƒ•MT)ỲH–XQBsHKJXEf_H\J|DqPGHKỲiYzNQcxDGFIT[•MTWÌH\XdBý—}˜03šd›vHKB_i_V·J|nYJ|DGTWZ»K¼W½Z[N f_T)aœÁDGHKNdBSNdcDGFIT]—}˜03šQ›~HKB iYV6N>^rTWPjX;DGHKBIg[J|n_J|DGT)Z XdBIfh)iYPqPGTWB DGamn6L'HmDGF¿ Ģ® ²u± °§Â \µMh)NdBYe=gdiYPjX;DGH\NdBIJ'X;PGTM¦>XQaKH–f$h)NdBYe=gdiYPjX;DGH\NdBIJODGFIXQDxJGX;DGH\J|c–nHKB„DGTWPjXQhWD0L'HmDGFETpXQh‘FENQDGFITWP0HKBE¦>X;PGHKN>iIJ'LxX)n_J)k+w ^IXdhjR>XQg>T Z$X)nSf_TWzDGFYTMiIJqTWP'PGTpº„iYHKPGTWZ[T)B„DGJ)ÁIXQB=ff_HKDGHKNdB=XdaKamn{JGXQDGHKJ|c’nJqN>Z[T3N>^_DGHKZ$XdaKHmD‡n6hWPGHmDGTWPGH\X_k^rTWB=f$N>B{c’iIBYhWDGHKN>B=XQaKHKDCn6^YPGN;¦ H–f_Tpf$` n6XQBINQDGFITWP'NdBIT>“ D‡LN^IXdhjR>XQg>T)J¿ ©‘à ±œ² ³ ° ~h)N>B_e=gdiYPjXQDGHKNdBIJyXQPGT3JqiYHKDjXQÌaKT3h)NdBYe=gdiYPjX;DGH\NdBIJxDGF=X;D0X>f_zZ$X)n[hWN>B(IHKhWDOL'HmDGFTpXQh‘F6NdDGFYTWPp“YXdBIf{X ^=XQh‘RdXdgdTMZ$X)nUPGT)h)NdZ[Z[T)B=f@‡B‚DGFIHKJ}LNdPGRELOTUc’NdPGZ$XQa\HKt)TUX{JqiIỲJqTWD NdcDGFIT•}T)ÌH\XdB€h)N>B_e=gdiYzXQBINQDGFITWP'^IXdhjR>XQg>T>kPjX;DGHKN>BE^YPGNdÌaKT)Z XdBIfJqFINpL FYNpL LOT hpXQB‚fYTWeIBIT]XdBENd^YDGHKZ[HKtpXQDGHKNdBLT)HKg>F„DMc’iIBIh‘DGH\NdB€c’NdP HmDpkv@‡B‚^=X;PqDGH\hWiIa\XQPp“+DGFIHKJMLT)HKg>F„DMcuiYBIhWDGHKNdBoXdamzaKNpL'J$X‚J|nYJ|DGTWZX>f_Z[HKBIHKJ|DqPjXQDGNQPUDGN†f_TWe=BYTX‚JqTWD[NQc(ITWV_HKÌaKTFYN>J|DiYPjX;DGH\NdBIJ'XQB=f$N>^YDGHKZ[HKtpX;DGH\NdBHKJqJqiITWJxF=Xp¦§T0PGTWh)T)HK¦§Tpf$aKT)JqJyXQDqDGT)B„DGHKN>BvklOFYTMZ$XdHKB{XdHKZÈNQc1DGFIHKJOLONQPGR$H\JODGNfYTWeIBIT}X‰cuNQPGZ$Xdarc’PjXQZ[TWLONQPGRcuNQP}TWVYXQZ[H\BYHKBIgDGFYT]Nd^YDGHKZ[HKtpXQDGHKNdBS^YPGNdÌaKT)ZSk=@CBSZ[N>J|DyhpXQJqT)J'DGFITWPGT^_PGNdeIa\TWJyDGFIXQD}XdhWDMXdJMf_TWcœXQiIamDMhWN>BYeIg>i_PjXQDGHKN>BYJ)k+lOFIT]h)N>Z[^YaKTWDGT •MTWzỲH\XdBhWN>BYeIg>i_PjXQDGHKN>BEZ[N f_T)a+H\J'^_PGT)JqT)B„DGTpf{HKBo»m¼"d½õkHKJ}BIN$JqHKBIgdaKT‰Nd^YDGHKZ$Xda1hWN>BYeIg>i_PjXQDGHKN>B·XdJ}fYHmÇ+TWPGT)B„D0iIJqTWPGJ0F=Xp¦§T]fYHmc–z*,+ --/. ¡y& ,©Ÿ !‡ -10,.-. ¡ ,2./)fYTWh)a\XQPjXQDGHK¦§T'PGiIaKTWz ÌXdJqTpfc’NdPGZ$XdaIa–XQBYz@CBDGFIHKJ§JqT)hWDGHKN>B[LOTy^YPGTWJqT)B„DOXkgdi=XQg>T3}›UDGF=X;DHKJX0JqiIỲJqTWDNdcIDGFITa\XQBIg>iIXdgdT3}›{fYTWeIBITpf3HKB»m¼Q½cuTWPGTWB DBYT)Tpf_J)k>lOF iYJ)“QLT'fYTWeIBIT.DGFITNd^YDGHKZ$XdaKHmD‡n]NQcrX}h)NdBYeIg>iYPjX;DGHKN>BDGNXJq^rT)h)Hme=h‚©jà ±œ² ³ ²KÉ;°Q±œ² ©dª6Ê ® ªr¨ ±œ² ©dªIkƒlOFITXdamLxX)n_J3L'HmDGF†PGT)Jq^rT)hWD`=XQJqH\h'H\fYT)XMH\J.DGNMT)J|DjXQÌaKHKJqF{XM^_PGTWcuT‘PGT)BIh)TxPGT)a\X;DGH\NdB[L'FITWPGTxLOT'^_PGTWcuTWPXUh)N>B_e=gdiYPjXQDGHKNdB·N;¦§T‘PMXQBINdDGFYTWP0HKc.HmDMgdHK¦§T)J0X$`rT‘DqDGTWP}¦dXdaKiYT c’NdP0DGFITcuiYBIhWDGHKN>Bvk„lOFYH\JPGT)a\XQDGHKNdB[H\J§XMJ|DqPGHKhWD§^=XQPqDGH\XQaINdPjf_TWP§NQ¦>TWP§X}e=BIHmDGTxJqTWDlOFYTxa\XdBIgdi=XQg>TyF=XdJ§X}cuNQPGZ$XdaYJqT)Z$XdB„DGHKh)J©DGF=X;D§HKJ.`=XQJqTpfN>BUDGFYTxJ|DjXQzË[Ì.ÍjÎmÏCÐmѧÒQÐÓ.ѧÐÔ;ÍGՇχÐׂ֜Ø)Ù'ÚrÍGÛ|Ü>ѧØpÎmØpÝ)×;Þ.ßÍGà>Ö‘á1Ø)Ù0â©Øpã3à>ä>Ö‡ÍGÕ‰ådÛGÐmÍGѧÛGÍỲaKTEZ[N fYT)a0JqT)Z$XdB„DGHKh)J[cuNQPSBINQPGZ$XdayaKN>g>HKh·^YPGNdgdPjXdZ[J·» ¤Q½õkO@CB¥DGFIHKJLNdPGRDGFYT JqT)Z$XdB„DGHKh)JyH\J0^YPGT)JqTWB DGT)f‚NdBIamnSHKB_cuNdPGZ$XQaKaKnEXdB=fDGFYT]c’NdPqzæ ѧçyèƒÑ>ݧámÞWé æ)ê ØpÕ æ Ö‡ØpÕ ×xÙ’ØpÕ=ÚܧÍGØpÕCÍGÖCÐmÛ æ ΄â1Øpã3à§ä>ÖCÍGÕvådÛGÐmÍGѧÛGÍ;Þ)ëváì0áí1Øjîï)ð;ñpñ Þ„ò+óõôö ñp÷pñ 2 ï ÌÓ.Ú'Þ>ò+ÐmѧÎæ ѧçIÞ>ÚrØpã3ã3ÐuáåQ×>Õ–ø æ Ñ>ÍjÑ„ùÜdä>ÖjáúÅ&%

Ë"7"8"8"897 ¦;: 7 5 ¼ :4654 HKJ§X}^YPGTpf_HKhpXQDGT'J|n_Z`rNdaIXQB=f< Ë DGN= ¦ X;PGT0XQaKa=¦>X;PGH\XdÌaKT)J.NdPL'FITWPGT\µ ¸ DGF=XQDyFIX;¦>T}D‡LNU^rN>JqJqHKÌaKT3cuNQPGZ[J)¾¯‘®Ë 7"8"8"897 A ¦ 5 ¤ :?!@BA? Ë 7"8"898D7 ?FEHGI@BA Ë 7"8"8"897 A ¦ 7 5J :CË “ 898"8 “? E c’NdPGZDGFYT0PGiIaKT LYµ ° ´XdBIfL'FYTWPGT}DGFYTMXQDGNdZ[J£?SXdBIfK?Ë “ 8"8"8 “MA ¦ cuNQPGZDGFITSPGiYa\T  ©p´'NdkOlOFITSPGiIaKT)J$NQc3DGFITDGFITSaKHmDGTWPjXQa\JKA5 ¤ : X;PGTUhpXdaKaKTpf ÂG°dĢ² ¨ ¯j® \µ ¸ XdBIf‚DGFYT‰PGiYa\TWJ3NdcODGFYT‰cuNQPGZ 5J :cuNQPGZR B·DGFYTUNdDGFYTWP F=XQB=f+“~HmcODGFYT`rN f n€NQc'X{hjFINdHKh)TUPGiIaKTUHKJ3DqPGiIT>“~XQB n±œ² ³ ²KÉ µ Ģ± °d± µ‘³$µ‘ª ±œ¸ Ndc©DGFIT0cuNdPGZF=Xp¦§T[©jÃ["\ C 465^] : ¾&_ 5^] : G 8 5^` :VW"X©YZVIY465^] : ¾_ 5^] : fYT)BYNdDGT)JyDGFIT JqTWDMNQcOX;DGN>Z[J 465^] : cuNQPlOFIT]BINQDjXQDGHKN>B5^] : HKJOXQa\JqN DqPGiITdk„lOFITyHKB„DGiIHmDGHK¦§TxZ[TpXdBYHKBIg3Ndc~XQB[N>^YDGHKZ[HKt)TL'FIHKhjF¡_DUH\JUDGFIXQD[LTLxXQB D[DGN·e=BIf X·J|DjXdÌaKTEZ[N f_T)aODGF=X;D$F=XdJJ|DjXQDGT)Z[TWB["\ C BINdD 465^] : ¾§_ 5^] : G 8 5 % :VWX©YaV=Y@CcYDGFITWPGTXQPGTxZ[NdPGT.DGF=XQB‰NdBITOZ$X;VYHKZ[HKt)T§J|DjXQDGT)Z[T)B„DGJ1HKBX0^YPGNdgdPjXQZS“aKTpXdJ|D0HKZ[^rNdPqDjXdB„D'XQB=f{DGFYTMa\XdJ|DyN>BYT3`rT)HKBIgDGFYT3Z[N>J|D'HKZ[^rNdPqDjXQB„Dpk²uĢ± µ‘ªr¨jµ$©|Ê °{Ģ± °§Â \µU³[©p´„µW.©|Ê °$­d¯ © ® ªr´ŽM9cb;d2br7e’8efb;gih1jDLIµ$µlklOFIHKJ'^YPGNd^rN>JqHmDGHKN>BEf_N„T)J'BINdDOBIT)h)TWJqJGXQPGHKamnSFINda\f6cuNQPy^YPGN>gQPjXdZ[JOL'HmDGFDGFYTUJqT)Z$XQB DGHKh)J3NQc'XBYN>BYz gQPGN>iIBIfs0›ý^_PGN>gdPjXQZ H\J¦>X;PGH\XdÌaKT)J]XQJfYTWeIBITpfSHKBEDGTWPGZ[JyNdc§HmDGJ/t}T‘PGỲPjXdBIfSHKBIJ|DjXdB„DGH\XQDGHKNdB·L'FYH\hjF‚Z$X)n`rTrÅ ¨+ -£-I. ¡0& ,Ÿ !‡ -wv x /6xzyu¬1­d® ¯q°d±œ² ©dªs³[©p´„µW|{=}h)NdBIJqHKJ|DGJ3NdcX6JqT‘D3Ndc§N>`~Q|T)h‘DGJHI€pw¨G©dªDCn_^rT)J'XQPGT>¾XdB ² ª=¨j©Q³}à °d±œ²õÂW² ²u± N6h)N>BYJ|DqPjXdHKB„D XdJqJqTWPqDGJ0DGF=XQD0D‡LN6hWN>Z[^rN>BYT)B„DGJXQPGT3Z‰iYDGi=XQaKaKn$T‘VYhWa\iYJqHK¦§T>Á¿€D k HKJyfYT)BYNdDGTpfĢ®_²’± °§Â \µ 5 fYT)BYNdDGTpf¡ˆ£‹{=}•”$ :gQPjXdZ>„|“k_wh)N>B_e=g>i_PjXQDGHKN>B!ŷH\J•MTWÌH\XdB hWN>BYeIg>i_PjXQDGHKN>B Z[N fYTWa‰^_PGT)JqT)B„DGTpf FYTWPGTlOFYTAJqH\Z[^YaKHKeITpfhWN>B„DjXdHKBIJ‰N>BYaKn†DGFIT6Z[N>J|D‰`=XdJqHKh6cuTpX;DGiYPGT)JUNQc0DGFYT$•MT)ÌH\XQBýhWN>BYeIgdzi_PjXQDGHKN>BÄJ|n_J|DGT)ZSk§…oT·iIJqT‚DGFIT·Xp¦>XQH\a\XQÌaKT†JqNQc’D‡LOXQPGTo^IXdhjR>XQg>T)JXdJf_T)aœ¾ Z[N´„µCÃYµ‘ªr´§µ‘ªr¨9N=¾0wû^=XQh‘RdXdgdT ´„µCÃYµ‘ª=´ ¸ ©QªŠXs^=XQh‘RdXdgdTŸžŠHmcUhpXdBYBINQD'`rT3iIJqTpf{XQD0XdaKaƒHmcHž·HKJyBYNdDyHKBIJ|DjXQa\aKTpf{H\B{DGFITMJ|n_J|DGT)ZSk¿fYTWa\T)f6L'HmDGFcœXQhWDGJyNdc1DGFYT}cuNQPGZlOFYT3^=XQh‘RdXdgdT)JyXQPGT3Z[N5l§ : @ 8 5¨ :¢'W§£§¤¥Wc¦©\lOFIT‚^IXdhjR>XQg>T)J{F=Xp¦§T·fYHmÇ+TWPGT)B„D{^YPGHKNdPGHmDCn¥aKT)¦§T)aKJ{DGFIXQD6DGT)aKa3FINpLJ|n_J|DGT)ZSk1…†T{iYJqTFYTWPGTHKZ[^rNQPqDjXdB„D[X‚^=XQh‘RdXdgdTHKJDGN‚DGFIT6•MT)ÌH\XQBWT«'¬TW&­f¬ XQB=f® ¢ ª Y ® «'W~¯kƒw"^=XdhjRdXdg>T[HKJNdBIamn·D‡LONE^_PGHKNdPGHmD‡n€aKT)¦§T)aKJ)“6©zª§ L'HmDGFEX]cœXdh‘DX‰J|DjXdB=fYXQPjf6^=XdhjRdXdg>TWT«'¬TW&­f¬ 5l§ : @ 8 5 :©zªZ$XdavfYT‘e=BIHmDGHKN>BhpXdB{`rTMcuN>iYB=f6H\B†»K¼"d½õk°d± ©Q³ NQc1DGFIT0cuNdPGZlOFYT3`=XQJqH\h3a\XQBIg>iIXdgdT]hWN>Z[^rN>BYT)B„D'HKJ0XQBXQB=f X€JqTWDK‚I€pNQcMPGT)a\XQDGHKNdBIJqFIHK^YJ6`rT‘D‡LOTWT)B¥Nd`ƒQ‡T)hWDGJ)kxlOFYTSPGT)a\XQzDGJ.DGF=X;DxfYT‘e=BITxL'FIXQDDGHKNdBIJqFIHK^YJiIJqiIXdaKamnUHKBIhWa\iIfYT0X3JqTWDONQc~hWN>BIJ|DqPjXQHKBhWN>ZỲHKB=XQDGHKNdBIJyNdc.N>`~Q|T)h‘DGJ3XQPGT aKT)g§XQaœkƒlOFYT Z[N>J|D0iIJqi=XQa1h)NdBIJ|DqPjXdHKB„Dh)N>BYJ|DjXdB„DGJ)kI…†TML'HKa\a~iIJqTMDGFYT3h)N>B ¦§T)B„DGHKN>B{DGF=XQD0XQa\a~¦>X;PGH\XdÌaKT)JyJ|DjXQPqDL'HmDGF[X}hpXQ^IHmDjXdaYa\T‘DqDGTWPOXQB=f‰XdaKaIh)NdBIJ|DjXQB DGJ©L'HmDGF[XMaKNpLOTWP§hpXQJqTyaKTWDqDGT‘PpkwŠ²u± µ ¯q° vHKJxT)HmDGFITWPxXdB{XQDGN>Z> UNdP'HmDGJOBYT)g§X;DGH\NdBBYNdD3 rk_w¥aKHKDGT‘PjXdavH\J¿ X¥´„µCÃYµ‘ª=´„µ‘ªr¨9N h)NdBIJ|DqPjXdHKB„D{XdJqJqTWPqDGJ[DGFIXQD6X†h)NdZ[^rN>BYT)B„D[BIT)T)fYJX ­d¯ © ® ª=´{²u± µ ¯|° ƒHmcHmDyfYN„TWJ0BYNdD'F=Xp¦§TMXdB„n6¦>X;PGH–XQÌaKT)J)kXdBYNdDGFIT‘P0hWN>Z[^rN>BYT)B„DODGNLNdPGR6^YPGN>^rT‘PGaKn+ÁIXdBIf…†T'T)BIh)N f_TxDGFITxPGT)a\XQDGHKN>BYJqFIHK^IJ`rTWD‡LT)T)B6XQDGNdZ[J§iYJqH\BYg H\B_cuTWPGTWBIh)T¿ X†ÖLY© ² ¨jµ$h)NdBIJ|DqPjXQH\B„D‰XdJqJqT‘PqDGJ]DGFIXQD3LOTF=Xp¦§TDGNShjFIN„NdJqT[N>BYT[NdPZ[NdPGTMhWN>Z[^rN>BYT)B„DGJxNdcX‰g>HK¦§T)BSJqT‘D0HKB„DGN‰DGFYT3h)N>B_e=gdiYPjXQDGHKNdB~k@CBDGFIHKJ'LONQPGREXUh)N>B_e=gdiYPjXQDGHKNdB·Z[N f_T)avH\J}fYTWeIBITpf{` nX$}›†^_PGNdzgQPjXdZ…„ €pXdBIf‰DGFITWPGT'HKJ§X3fYHmPGT)hWD§h)NdPqPGTWJq^rN>B=f_T)BIhWT0`rTWDCLOT)TWBUaKT)g§XQafYTWa\J'NQc2„†€p‚k_…oTMhpXQBST)J|zhWN>BYeIg>i_PjXQDGHKN>BYJyNQc|{=}XQB=f{J|DjXQÌaKT3Z[NQ|T)h‘DGH\NdB#‡.©dª)Ê6DGFIXQDDjXQÌaKHKJqF6DGFYHKJOh)NdPqPGTWJq^rN>B=f_T)BIhWTM`„n$fYTWeIBIHKBIg]X]ÌHZ$XQ^IJxJqTWDGJyNdc.X;DGN>Z[JxDGN[h)NdBYe=gdiYPjX;DGH\NdBIJ0XdBIf¦ H\hWT3¦§TWPGJGX_kI@‡BSZ[NdJ|DH\XdarDGNUf_TWe=BYT>k_lOFITyPGTpXdJqNdBDGN]JqT)^=X;PjXQDGTh)XdJqT)JODGFYH\JOc’iIBYhWDGHKN>B6H\JODqPGHK¦fYTWac–PGN>Z DGFYTU^YPGNdgdPjXdZ DGFIXQD‰fYT‘e=BITWJ3HKD HKJ3DGF=X;D3DGFITU^_PGNdzDGFYTUZ[NXQPGTMh)XdaKaKTpfoÖLY© ² ¨‘µ ¯‘® \µ ¸ kYw¤ÌXdJqHKh}PGiIaKT}L'HmDGFXdBTWZ[^YD‡nPGiIaKTM`rN f_ngQPjXdZûZ$X)n‚F=Xp¦§TUXJqTWD]NdcyXQiYV_HKa\H\X;PqnoX;DGN>Z[JMDGF=X;D‰fYNBYNdD]F=Xp¦§TUXHKJyh)XdaKaKTpfEXMÊ ° ¨ ± kIwP0›·Ã ¯ © ­d¯q° ³ HKJyXJqTWDyNdc©PGiYa\TWJ)k…†T†X;PGT†HKB„DGTWPGT)J|DGTpf¥HKBÄe=B=f_HKBIgsJ|DjXdỲaKToZ[N fYT)aKJ{Ndc0›Š^YPGNdzgdPjXQZ[J)kr@‡B„DGiIHmDGHK¦§T)amn„“=X$J|DjXQÌaKTZ[N f_T)a1HKJMX[JqTWDMNdcXQDGN>Z[J'DGF=X;DMJGX;Dqzf_HmPGT)hWDh)NQPqPGT)Jq^rN>BIfYT)B„DHKBDGFIT§h)N>B_e=gdiYPjXQDGHKNdBUZ[N fYT)aœkQ@CD©LN>iYa–fXdaKJqN`rT$^rNdJqJqH\ỲaKT6DGN‚f_TWe=BYT$XSh)N>B_e=g>i_PjXQDGHKN>BAZ[N f_T)a§iYJqHKBIg‚NdDGFYTWP‰c’NdPqzZ$XQaKH\JqZ[J)“pc’NdP©T‘VIXQZ[^IaKTJqNdZ[T§NQcIDGFYTZ$XdB„n}h)N>BYJ|DqPjXdHKB„DJGXQDGHKJ|cœXQhWDGHKN>BHKJ|e=T)J0XdaKaƒPGiYa\TWJ0NQc©DGFIT3^YPGNdgdPjXQZbXQB=fTpXQh‘F‚X;DGN>ZHKBSHmD}HKJ2Q|iYJ|DGHKeITpfHKB†DGFIT[JqT)BYJqT[DGF=XQD]HmD]N„h)h)i_PGJ‰HKBsXPGiYa\T[FYTpX>f·DGF=XQD]FIXdJ]HKDGJ]`rN f_nXQ^I^_PGN§XdhjFITWJ)kJGXQDGHKJ|e=T)f6HKB[DGFITyZ[N fYT)aœk w¥ÌXdJqHKh0PGiYa\T}XdJqJqTWPqDGJ§DGF=XQDOHKcvDGFITy`rN f_nNdcw ¨G©dª ¬ƒ­d®_¯|°d±œ² ©dª‰ˆ6HKJUJqHKZ[^IamnAX‚JqiIỲJqTWD[NdcI €p k.wh)N>B_e=gdiYzPjX;DGHKN>BŠˆ[HKJ À ° ² ´ 5 fYT)BYNdDGTpfˆK‹Œ{=} : HmÇýDGFITWPGT$TWV_HKJ|DGJUXSJ|DjXQÌaKTX6PGiYa\T‰HKJMDqPGiIT>“rDGFYT)B·DGFYTFYTpX>f‚Ndc§DGFIT‰PGiYaKTUF=XQJMDGN{`rT]DqPGiIT[XQa\JqN_kB iIZ`rT‘PNdc+FIT)X>f[XQDGNdZ[JS? Ë “ 8"8"8 “T? E hpXQB[`rTyHKBUDGFYTxZ[N fYT)aœk„lOF iYJ)“Z[N f_T)a }NQc6„ €pJqiIhjFUDGF=X;DB·cuNQP]X6JqTWD NQcxX;DGN>Z[J}DGN6`rTHKBhWN>BYeIg>i_PjXQDGHKN>BYJyNQc|{=}XEZ[N fYT)aOỲiYD‰HmDUf_N„T)JUBINQDc’NdPGh)T6DGFIT)ZûDGN‚`rT{HKBAHmDpk©@Cc0XQB X;DGN>ZwÄJqTWD/”Ndc ®_¸ µ ¯3¯ µ’‘ ® ²u¯ µ‘³$µ‘ª ±œ¸ HKJOPGT)^YPGT)JqTWB DGT)f6`„n6X0›‚^_PGNdzHmÇ$DGFIT‘PGTyT‘VYHKJ|DGJ§X}J|DjXdỲaKT0Z[N f_T)a;}Ndc~XM^YPGNdgdPjXQZ–„ €D ”I„ “ JqiIhjFf_n„“YHKDfYN„T)JyBINQDyN„h)h)iYP}XdJ}XUFITpXdfNdc.XPGiYaKT]FIXp¦_HKBYg[XUJGXQDGHKJ|e=T)fS`rNfYT)aœkhpXdBYBINQD0`rT0DqPGiIT3HKB{DGFYTMZ[Nk €pš /P›¥/Dœ ! ,.- + --/. ¡y& ,©Ÿ !‡ -wv x /6xˆdk.lOFIT6JqTWDNdc}XdaKa'JqiIHmDjXdỲa\T6h)NdBYe=gdiYPjX;DGH\NdBIJUHKJ5 } :$Ž DGFIXQD—‡.©dªpÊ“ f_T)BINQDGTpf!˜@CBsX>fYfYHmDGHKN>BoDGNPGiYaKT)JUXQB=foX;DGN>Z[J]XU0›¥^_PGN>gdPjXQZ Z$Xpn†XdaKJqNNdiYP.h)NdBYe=gdiYPjX;DGH\NdB[N>`~Q|T)h‘DGJ)k„lOFIT‘PGT0X;PGTxDGFYPGT)TOPGT)a\X;DGH\NdBIJqFYH\^YJ§HKBDGFYTXdJ'Z$XdB„n$NQc1DGFIT 465^] : JODqPGiIT3XQJy^rNdJqJqHKÌaKT>k=…†TMhpXdBXdaKJqN[Z[HKBIHKZ[HKt)TiIZ‰`rTWPNdc~XQDGNdZ[J§DGFIXQDXQPGTyH\B$X3Z[N f_T)aY`„nZ$XQV_HKZ[H\tWH\BYg}DGFITWHKPDGFIT'Bh)N>Z[^YaKT)Z[T)B„DGJ)¾¿ ¨G©dª ² ¨ ± ¾~w£^IXdhjR>XQg>T$ ¨G©dª" ² ¨ ±œ¸$¡²u± L€X6^=XQh‘RdXdgdTžAHmc=ÄXdBIfž†X;PGT3Zi_DGi=XdaKamn$TWV_h)aKiIJqHK¦§Tdk¿ ¯ µq¨G©d³³[µ‘ªr´ °Q±œ² ©dª1¾vw ^IXdhjR>XQg>TH ¯ µq¨j©Q³³$µ‘ª=´ ¸ XU^=XQh‘RdXdgdTž†HmcDGFITWnUXQPGTyh)N>BYJqH\fYTWPGTpf$HKBUeIV_TpfUNQPjfYTWP§L'HKDGF[DGFYTyeYPGJ|DNdBITy`rT)HKBIg DGFITž€JqHKgdBIHme=hpXQB„DGaKn{T)BYF=XdBYh)T)JODGFYTMcuiIBYhWDGHKN>BIXdaKHmD‡n{Ndc£xk¯ © ­d¯q° ³ ²u¸m!n «C¨G©d³}Ãr\µ ± µo0›€ÃŽM9cbpbFqj?ƒlOFIHKJ'^YPGNd^rN>JqHmDGHKN>BEHKJ'^YPGN;¦§Tpf6H\B†»K¼"d½õkJ|DjXQB=fYXQPjf†Hmc'HmD]JqFIN>iYa\f†`rT[^YPGT)JqTWB D]HKBsXQa\aO—}˜}Mšd›~HKB iYV·J|n_J|DGT)Z[J)“NQDGFITWPqL'HKJqTyHmDHKJNd^YDGHKN>BIXdaœk§…†T'DjXQR§TODGFITyXQ^I^YPGN>XdhjFUDGF=X;D§LT0f_T)BINQDGTTWV_^rN>BYT)B„DGH–XQa©HKB€JqHKt)T>kpt0N;LT)¦§TWPp“+HKB‚Z[N>J|DM^YPjXdh‘DGH\h)XdahpXdJqTWJMLOTh)XdBiIJqT3HKBIJ|DjXQB„DGH–X;DGHKN>BIJxDGFIXQD0XQPGT3T)HmDGFYTWPya\HKBYTpXQPyNdP0º„i=Xdf_PjX;DGH\hdk

lOFYT$h)N>B_e=g>i_PjXQDGHKN>BYJUX;PGT{Z[N f_T)aKTpfoiIJqHKBIgSDGFYT$^YPGTpf_H\h)XQDGT YZ«T² §´³5 } :2Ž C §s YZ«T² §´³|· }PG 5 Å :‡.©QªpÊ…oTyL'H\aKavDjXdR§TyDGFIT3XQ^I^YPGN>XdhjF{DGFIXQD'X]^=XdhjRdXdg>T}Z$Xpn$`rTMX>fIf_Tpf[DGNUXh)N>B_e=gdiYPjXQDGHKNdBSN>BYaKn{Hmc1LOT3h)XdBBYJ|DqPjXdHKB„DGJ)¾…oTM^_PGiIBYTMN>i_D0HKB¬T\§¢&\§«'¬ © 5l§´½ 7 §F¾ : 7 YZ« 5l§´½ : 7 « ®'ª YZ« 5l§;¾ : 5 ¼ :@£ ® «°;Y £ ª¥© 5l§ ½ 7 § ¾ : 7 YZ« 5l§ ½ : 7 Ya« 5l§ ¾ : 8 5 ¼>¼ :@iYHmPGT)Z[T)B„DGJƒX;PGTOZ[N fYTWa\T)f iYJqHKBIg'D‡LONy^YPGT)fYHKhpXQDGTWJ)“ º © \§­Z¿lOFIT§iIJqTWP1PGT)ºYZ«'£§¯ º ¬T\'² §´³ XdBIf º © \§­Z¿»\’X§£§¯ º ¬T\§² §´³ “0cuNQPo^=XQh‘RdXdgdT)J€DGFIXQD€DGFITAiIJqTWPcuNda\aKNpL'HKBIg[D‡LNUh)NdBIJ|DqPjXdHKB„DGJ)¾º © \'­À¿¥YZ«'£'¯ º ¬T\ 5l§ : 7 « ®§ª YZ« 5l§ : 5 ¼c¤ :@º © \'­À¿z\OX§£'¯ º ¬T\ 5l§ : 7 YZ« 5l§ : 8 5 ¼ J :@fYT)aœ“_X ^=XQh‘RdXdgdT}HKJÁQ|iYJ|DGHme=Tpf$HmcƒDGFITyiIJqT‘PxTWV_^IaKHKh)HmDGamn@‡B[DGFITy`=XQJqHKhMZ[N²uĢ± µ‘ªr¨jµ0©‡Ê ° ¨G©dª ¬1­d® ¯q°Q±œ² ©dª}Ê)© ¯x°Å µ ÂW²õ° ªŽM9cb;d2br7e’8efb;gÄÕjDLIµyµlk¬ƒ­d®_¯|°d±œ² ©dª€³[©p´„µW ²u¸3mKn «C¨G©d³}Ã=\µ ± µo¨G©dªŽM9cbpbFqj?JqHmDGHKN>Bȼ€LOTsN>BYamn¤FIXp¦§T†DGN^_PGNQ¦>T†DGF=X;DEDGFITfYTWaYHKJ.^rN>amn_BIN>Z[H\XQagdPGNdiIB=f‰H\BYJ|DjXdB„DGH\XQDGHKN>B[NQcrDGFITxh)NdBYeIg>iYPjX;DGHKN>B[Z[NNdc1DGFYTMZ[N fYTWaõkL'HmDGFPGT)Jq^rT)hWD'DGNDGFYTMJqHKt)TDGH\X;DGH\NdBSHKJxaKH\BYTpXQPyJqHKBIhWTMZ[N>J|D@CB{^_PjXdhWDGHKh)T0DGFIT}JqHKt)T3NQcƒDGFYT}HKBIJ|DjXQBNdc]DGFIT·^=XQh‘RdXdgdT)JEXQPGT€HKB¤XsPGT)a\XQDGHKNdB”L'HmDGF”a\TWJqJDGF=XQBÄDGTWB”NQDGFITWP^=XQh‘RdXdgdT)J)kÊDMiIJqTWPGJ3FIX;¦>TUfYHmÇ+TWPGTWB D3PGT)º iYHmPGT)Z[T)B„DGJ)“=LOTUfYTWeIBIT‰DGFYTwyJ3fYHmÇ+TWPGTWBNd^YDGHKZ$XdaKHmD‡nNdcƒX]hWN>BYeIg>i_PjXQDGHKN>B{XdamLxX)n_JL'HmDGF[PGT)Jq^rT)hWDDGN]JqNdZ[T0Nd^YzDGHKZ[HKtpX;DGH\NdBscuiIBYhWDGHKN>BÑÐýXdB=f†DGFYTWPGT6Z$Xpn€`rT6Z$XdB„n†Nd^YDGHKZ[HKtpXQDGHKNdBFIXdJyXFYH\gdFITWP'LT)HKg>F„D'DGF=XdBKˆpŒdkg6e’8e±b gÄhÏÖ ² À µ‘ª ° ¨G©dª ¬ƒ­d®_¯|°d±œ² ©dª³[©p´„µWƒ{=} ° ªr´ ° ¡ µ ²\­ L ±Ó!ÔTÕLYµ ¯ µW°Q±œ² ©dª ±5 {=} 7 Ð :ÜŽ CTÝ ˆ Ë7 ˆ)ŒÞ ˆ Ë7 ˆ)Œ · €D 7 Ð 5 ˆ Ë :3ß Ð 5 ˆpŒ : G 8 5 ¼" :„lOFYT•MT‘e=BIHmDGHKN>BļSHKZ[^rNdJqT)J$X·J|DqPGHKhWD$^IXQPqDGH\XdayNdPjf_TWP[NdBXdaKa'¦dXdaKH\ffYT)aœk —}HK¦§TWB$X JqT‘DNQc~iYJqTWP.PGTpº„iIHmPGT)Z[T)B„DGJ)“hWN>BYeIg>i_PjXQDGHKN>BYJNdc+DGFYTxZ[Nh)NdBYeIg>iYPjX;DGHKN>BIJ)kLT3hpXdB{PGT)J|DqPGHKhWD'DGFIHKJxPGT)a\XQDGHKN>BDGNJqiIHmDjXdỲa\TÓ!ÔTÕ g6e’8e±b g‰ÃàÖ ² À µ‘ª ° ¨G©dª ¬1­d® ¯q°Q±œ² ©dª¥³U©p´„µW†{=} Û °‚¸ µ ±5 {=} 7 7 Ð : ²’¸}± LIµ ¯ µW°d±œ² ©dªPGTWJ|DqPGH\h‘DGTpf^YPGT‘cuTWPGT)BYh)TMPGT)a\XQDGHKNdB‚5 {=} 7 7 Ð :ÜŽ C~Ý ˆ Ë7 ˆpŒÞ ˆ Ë7 ˆpŒ · ˜ “€p 7 Ð 5 ˆ Ë :Sß Ð 5 ˆ)Œ : G 8‚¤' : 5Nd^YDGHKZ$Xda h)NdBYe=gdiYPjX;DGH\NdBŠHKJ€X Z[H\BYHKZ$Xda T)aKT)Z[T)B„D‚Ndc[DGFYT†PGTWzwyBJ|DqPGHKhWDGT)f^YPGTWc’TWPGT)BYh)TMPGT)a\XQDGHKN>Bvkg6e’8e±b g‰áàÖ ² À µ‘ª ° ¨G©dª ¬1­d® ¯q°Q±œ² ©dª¥³U©p´„µW†{=} Û °‚¸ µ ±Ó!ÔTÕ° ªr´6©dª= N ²ÊMˆ ²’¸3° ³ ² ª ² ³ ° ~µW\µ‘³[µ‘ª ± ©‡Ê‚ 5 {=} 7 7 Ð : o²ÊwyamDGTWPGB=X;DGH\¦>T)amn„“=LOT‰h)N>iYa–fEDqPqnSDGN6aKTpXp¦§TNdiYD}DGFYTUf_TWe=BYHKDGHKNdB·NQc§DGFYT„ 5 {=} 7 Ð : k~t}NpLT)¦§TWPp“ DGFIHKJLN>iYa–f6hpXdiYJqT3X‰^_PGN>Ỳa\TWZ"L'FITWBU„ FIXdJ¨G©d³}à ®_± °> \µ ² ª ° Ã_©> Ndª=©d³ ²œ° ±œ² ³$µo²’¸NQDGF·PGTpº„iYHKPGTWZ[T)B„DGJ}X;PGTBITWh)T)JqJGXQPqn„k~lOFYTiI^Y^rTWPM`rNdiIBIf‚NQc§DGFYTËŠÌ Ÿ !‡ !»Í ,©Ÿ !‡ -ÏÎ ¡ - ¢ Ÿ !‡ -yw0aKa§NQDGFITWP©^IXdhjR>XQg>T)JƒXQPGT§h)N>BYJqH–f_TWPGTpfMDGNy`rT§Nd^YDGHKN>BIXdaœkQlOFIT.PGT)a\XQDGHKN>BYJf_T)aKTpfL'HmDGFK¤;zCXQPqn[^_PGTpfYHKhpX;DGT)J ¬T\'¢©\§«'¬ ©‘“`rTWD‡LT)T)B$^=XQh‘RdXdgdT)JOX;PGT0Z[N® «°;Y £ ª¥©W“IXdBIf ­±\"£ ® V V\§«'¬ ©‘k£DGF=X;D}HKJ0DqPGiYT‰HKB‚X[J|DjXdỲaKT‰Z[N f_T)aƒTWVYXQhWDGamnSL'FIT)BSDGFYT ^=XdhjRdXdg>T § H\Jc’iIBYhWDGHKN>BIJ0fYT‘e=BIT)f{cuNQP3X[h)N>B_e=gdiYPjXQDGHKNdBEZ[N fYT)aœkI…†T3DjXdR§T3DGFIT XQ^Yzh‘FYN>JqT)BSDGN`rT]HKBEXUhWN>BYeIg>i_PjXQDGHKN>Bvkr@‡BST‘Ç+T)hWDp“ILT]fYTWeIBIT}DGFYTµ‡.©QªpÊ^_PGN§XQh‘F DGF=X;D©N>^_DGH\Z[HKtpX;DGHKN>B cuiIBYhWDGHKN>BYJXQPGTxf_TWe=BYTpf XdJ1LOTWH\gdF„D©cuiIBYhWzÌH Q|TWhWDGHKN>B‚XdJ)¾DGHKNdBIJ)¾>DGFYTOcuiYBIhWDGHKN>B$XQJqJqHKg>BIJXdBUHKB„DGT)gQPjXdaYLT)HKg>F„D.cuNdPTpXdhjFUJqiYHKDjXQÌaKTLOT'h‘FYN„N>JqTODGFYTxN>BITOL'HmDGFUFYHKg>FITWJ|D.LT)HKg>F„Dpk&ÒINdPqzhWN>BYeIg>i_PjXQDGHKN>B[XQB=fZ$XQaKaKn„“QLOTyh)NdBIJ|DqPGiIh‘DOXM^_PGTWcuTWPGTWBIh)T'PGT)a\XQDGHKN>B$NdBUDGFIT'JqTWD§Ndc~XdaKa=h)NdBYzeIg>i_PjXQDGHKN>BYJ3JqN{DGF=X;DMLOT‰Ã ¯ µuÊpµ ¯ X6h)N>B_e=gdiYPjXQDGHKNdBˆ Ë N;¦§T‘P=ˆ Œ HmcSˆ ËÊ ® ª=¨ ±œ² ©dªsÐA¾; €DØ×ÚÙSÛ ± LYµ6^YPGT‘cuTWPGT)BYh)TUPGT)a\XQDGHKNdBŠ„ 5 {=} 7 Ð : ²u¸Jq^rT)h)Hme=h)XdaKamn6LOXdB„DGJONQPyfYN„T)JxBYNdDOLOXdB„DODGN]F=Xp¦§T>“„PGT)Jq^rTWhWDGHK¦§T)amn„k_lOFITPGTpº„iIHmPGT)Z[T)B„DGJ§XQPGT}X>fIf_Tpf$XdJcuXdhWDGJH\B[DGFYT0^_PGN>gdPjXQZÈXQJLOT)aKavXdJ§DGFIT©|ʸ µ Ū¯ µ’‘ ® ²u¯ µ‘³$µ‘ª ±œ¸ Û ° ª=´ °¡ µ ²\­ L ± Ê ® ª=¨ ±œ² ©dª—ÐA¾F˜ “€p ×BÙSÛ ± LIµ®DGN{`rT[H\B†Xh)NdBYe=gdiYPjX;DGH\NdB~“ƒXBITWh)T)JqJGXQPqn€^=XQh‘RdXdgdT$fYTWzJqT)aKT)hWDGTpf€HKD^rT)B=f_JON>B6HmDp“YXdB6H\BYh)aKi=f_Tpf[^=XdhjRdXdg>T0PGT)h)N>Z[Z[TWB=fYJ§HmDp“„DGFIT}^IXdhjR>XQg>THKJ0NdBIT Ndc©DGFYT3J|DjXdB=fYXQPjfS^IXdhjR>XQg>T)J)“INdP0HKc.HmDy`rT)aKN>BYg>J0DGN$XUJqTWa\TWhWDGTpf¨ k\¼dkFINdJ|D0^_PGNdeIa\Tdk=lOFYT3FIN>J|Dy^_PGNde=aKT)JyX;PGT3TWV_^Ia\XdHKBIT)f{HKBµ_TWhWDGHKN>B©»ª Y ¼\"¬ 5l§ : @ º © \§­Z¿lYa«'£§¯ º ¬T\ 5l§ : 5 ¼ ` :ļº©|Ê©dªˆ · ˜ “€D ²u¸U° ªAN>^YDGHKZ$XQa©h)N>B_e=g>i_PjXQDGHKN>B·L'HmDGF€PGT)Jq^rT)h‘D3DGNбœ²©»ª Y ¼\"¬ 5l§;¾ : @ ¬T\'¢©\§«'¬ © 5l§´½ 7 §;¾ : 7 YZ« 5l§ ½ : 5 ¼c% :ļº©»ª Y ¼\"¬ 5l§ ¾ : @ ­±\"£ ® VHV\§«'¬ © 5l§ ½ 7 § ¾ : 7 Ya« 5l§ ½ : 5 ¼ ¨ :ļº¸ µ ¯3¯ µl‘ ® ²u¯ µ‘³$µ‘ª ±œ¸ Û ° ªr´ ° Ê ® ªr¨ ±œ² ©dªKÐE¾§˜ “€p ×âÙSÛ ° ¨j©Qª ¬1­d® ¯|° «®©»ª Y ¼\"¬ 5l§ : @B©zª WT«'¬TW&­f¬ 5l§ : 5 ¼c :ļº©»ª Y ¼\"¬ 5l§ : @ Ya«¿ © \§¯ \"£ ª \"¬&¿’ ®&©»ª ¿’¢&­ ® ¼´¯ \ 5l§ : 5 ¼pÅ :ļºPGTWJ|DqPGH\h‘DGTpf ^_PGTWcuTWPGTWBIh)TSPGT)a\X;DGH\NdB¥XdBIf f_T)Z$XdBIfýNdBIamnsDGF=X;D6X€h)NdBYzeIg>i_PjXQDGHKN>B·F=XQJ}DGN{`rT‰`rNdDGF‚JqiIHmDjXQÌaKT[XdBIf‚X6Z[HKBIHKZ$XQa1T)aKT)Z[T)B„DMNQcBYNJqiYHKDjXQÌaKT Z[HKBIHKZiYZ[J)kDGFYTSLOT)HKgdF D$c’iIBIh‘DGH\NdBãÐ~kO@CB¥^YPjXQhWDGHKhpXdaMXd^I^YaKH\h)XQDGHKN>BYJ{DGFIT{LOT)HKg>F„DlOFITUfYTWeIBIHmDGHKN>BIJMXd`rN;¦§T[f_NBINQD HKZ[^rN>JqTUXQB„nEPGTpº„iIHmPGT)Z[T)B„DGJMNdBc’iIBYhWDGHKN>BJqFYN>iYa–f‰`rTOh)N>Z[^YiYDjX;DGH\NdB=XQa\amn cuT)XdJqHKÌaKT>k§…†TxfYT‘e=BITOX}h)a\XdJqJNQc}c’iIBIh‘DGH\NdBIJ)“.B=XQZ[T)amnsh)NdBIh)HKJqTSLOTWH\gdF„D[cuiIBYhWDGHKN>BYJ)“.DGFIXQD[FIXdJDGFYTlOFYTWPGT[X;PGTJqHmV‚PGiIaKT)JML'HmDGF€NdBIamn·N>BYT¦dXQPGH\XdỲa\TH\B‚DGFIT‰^YPGNdgdPjXdZ^_PGN>^rTWPqDCn‰DGFIXQD.DGFITxNd^YDGHKZ[HKtpXQDGHKN>B[^_PGN>Ỳa\TWZ£c’NdP.DGFIT)Z HKJ§HKB6‹ Œ 'ŽkklOFYHKJ'L'HKaKaƒ`rT3^_PGN;¦§Tpf$H\B_T)hWDGHKNdBµg6e’8e±b gŒä–å Ê ® ªr¨ ±œ² ©Qª—о´ €pæ×çÙ ²’¸[° hWN>BIhWH\JqT ¡ µ ²\­ L ±Ó!ÔTÕXdBIfcuN>i_PPGiYa\TWJ§L'HmDGF[D‡LON ¦dXQPGH\XdỲaKT)J)k_lOFITxPGiIaKT)J.L'HmDGF6NdBITy¦>X;PGH\XdÌaKTF=Xp¦§T©DGNy`rT§HKBIJ|DjXQB„DGH–X;DGTpf3N>BYh)T§c’NdP1T)XdhjF‰^IXdhjR>XQg>T.H\B3DGFYT§Z[N f_T)a„XdBIfDGFIT]PGiIaKT)J}L'HmDGF€DCLON6¦>X;PGH\XdÌaKT)J3NdBIh)T‰cuNdP TW¦§TWPqnE^IXdHmP3Ndc^=XQh‘RdXdgdT)J)kiIJ)“_HmcƒDGFIT‘PGT3XQPGT ^IXdhjR>XQg>T)J'HKB{DGFYT}Z[N fYTWaõ“ DGFYTWPGT}HKJyX]DGNQDjXda+NdclOF¼ :2Ž `&ŒÇ ¤ ¨§ÇÈ`&25^ÉÊ ® ª=¨ ±œ² ©dª ²Ê ° ªr´ý©dª= N ²Ê ± LIµ ¯ µoµlk ²’¸j±‰±^¡ © ¨G©dª ¸j± ° ª ±œ¸ Û 7 éèâ ÛÖL ± L °d± Ê)© ¯[° u¨G©dª ¬ƒ­d®_¯|°d±œ² ©dª ¸ ˆ Û Ð 5 ˆ : ê $¢&¤ ¦&¨ Û ¡ LYµ ¯ µ ²u¸Ģ®LYµ‰ª ® ³  µ ¯ ©‡Ê¨G©d³}Ã_©Qª+µ‘ª ±œ¸‰² ª ± LIµ[¨j©Qª ¬1­d® ¯|°d±œ² ©dªo³U©p´„µW Û ° ª=´¡Ð±cuNQP]DGFYTU^YPGNdgdPjXQZ XQB=f·HKDGJ JqHKt)T$HKJ ^rN>amn_BIN>Z[H\XQagdPGNdiIB=f·HKBIJ|DjXdBYh)T)JNdc1DGFYTMZ[N fYTWaõkrL'HmDGFPGT)Jq^rT)hWD'DGNDGFYTMJqHKt)T¦dXdaKiYT}T)BYJqiYPGT)JDGFIXQDOLT}FIX;¦>T0DGN]h)N>BYJqH–f_TWP'N>BYamn$^rN>amn_BIN>Z[H\XQarB_iYZUz`rT‘PNQc ^rNdDGT)B„DGH\XdaKamn¥N>^_DGHKZ$Xda0LT)HKg>F„DGJ{DGFYTSDGHKZ[T·`rNdiIBIf¥T)BIJqi_PGT)JDGFIXQDxLT3hpXdBShWN>Z[^Ii_DGT0DGFYT3¦>XQa\iYTMTWþ[hWH\TWB DGamn„kÅ©

ÚܧÍxà§Õ‡ÍqÙ–ÍGÕ‡ÍGѧÛGÍxÕ‡ÍGÎæ ÖCÐmØpÑØ)Ùvè~î æ ã3à§ÎmÍ 2íÜîÀïð;ñ9ò!óƒô: ÷—d6ø Ô h¤›~TWDX'h)NdBYe=gdiYPjX;DGH\NdB‰Z[N f_T)aƒ{=}`rTOf_TWe=BYTpf3` n}DGFITõö£ 7 ¬ @« ®'ª W 7 « ®§ª ì @5 ¤ ¼ :×ØÙ `rT0f_TWe=BYTpfUXQJ§cuNdaKa\NpL'J)¾5 ˆ :|Ž ˆ 8 5 ¤&¤ :И0NpLé{=}£F=XQJyBYHKBITM¦dXdaKH\fh)NdBYe=gdiYPjX;DGH\NdBIJ)¾Ž C$C W G ë C ì G ë C W~ëF£ G ë C W~ë¬ G ë C ì~ëF£ G 7€pì~ëF¬ G ë C Wƒë´ì G 7 C Wƒë´ì~ëF£ G ë C Wƒë´ì~냬 Gi_PGT€¼dklOFIT{^YPGTWc’TWPGT)BIhWT6PGT)a\X;DGH\NdBŒ„lOFITWPGT$X;PGTUD‡LNSh)N>B_e=gdiYPjXQDGHKNdBIJ]H\B—sDGF=XQD‰X;PGT[N>^YDGHKZ$XQaL'HmDGF†PGT‘zC W~ëpì~냣 GSXdBIf C Wƒë´ì~ë¬ G„kÜ iI^I^rNdJqT[DGF=XQDJq^rT)hWD‰DGNÐ~“1B=XdZ[TWaKn¬ HKJ'^YPGTWJqT)B„Dp¾JqNLOT3NdBIamnXdaKaKN;L¤h)NdBYe=gdiYPjX;DGH\NdBIJ'L'FITWPGT“€p Ž C$C W~ëF¬ G ë C ì~냬 G ë C W~ëpì~냬 G$G 8 5 ¤ ` :˜ú±œ² ³ ²KÉ;°Q±œ² ©dª€¨ ¯‘²’± µ ¯‘²õ° kh)N>B_e=gdiYPjXQDGHKNdBSN>`~Q|T)h‘DGJ0`„n6Z[TpXdBYJxNdc'©jÃg6e–8efb g‰ÿ…åyª·N>^_DGH\Z[HKtpX;DGHKN>BShWPGHmDGTWPGHKNdB{ ²u¸3°[¸ µ ±ÓKÔTÕŽ C¡ Ë7"898"87 ¦ G 5 ¤&% :{¨G©dª ¬ƒ­d®_¯|°d±œ² ©dªo© £¢ µq¨ ±œ¸ o ©|ÊXh)NdBYe=gdiYPjX;DGH\NdBDjXdJqRrkg6e–8efb g¥¤wÖ ² À µ‘ª ° ¨G©dª ¬1­d® ¯q°Q±œ² ©dªÈˆ ° ªr´ ° ª¥© ¯ ´„µ ¯ µG´ ±œ® Ãr\µÓKÔTÕ{ Ž 5 { Ë798"8"8"7 {§¦ : ©|ÊO©‘à ±œ² ³ ²\Ép°d±œ² ©Qª$¨ ¯‘²’± µ ¯‘²õ° Û ± LIµxLT)HKg>F„Dƒc’iIBYhWDGHKN>B¨ ¦ 5 ˆ :ÜŽ¦ ˈ 5 ¤ ¨ :ùˆ HKJ JqN]DGFYT'¦>XQa\iYT'Ndc ¨ ¦ 5 ˆ :Ë “ 8"8"8 “§{§¦'hpXQB‰`rT§fYT‘e=BIT)f3L'HmDGF3Z$XQV zlOFYTNd^YDGHKZ$XdaKHmD‡n3h‘PGHKDGT‘PGH–X/{HKZ[HKt)TMJ|DjX;DGT)Z[T)B„DGJ)¾[9\ C YZ« 5^] : ¾©{ Ë 5^] : GV/W"X©YZVIYkkk5 ¤§ :Ndc§DGFIHKJ}cuNQPGZiYa–X;DGHKN>B·H\J0DGF=XQD}LOTZ$X)nEiYJqTHmDlOFYTZ$XQH\B‚^_PGN>ÌaKT)ZL'FIT)B‰DGFITxN>^_DGHKZ$XdaKHmD‡n]hpXdB`rTxTWV_^YPGT)JqJqTpf]HKBDGTWPGZ[J©Ndc+Nd`ƒQ‡T)hWDGJNdBIamnDGFIXQD6X;PGTEH\BýDGFITShWN>BYeIg>i_PjXQDGHKN>Bvk@CB¥NdDGFYTWP6hpXdJqTWJ$LTSLONdiIa\f¥aKHKR§TDGJODGN‰F=Xp¦§T}DGFYTMcuNQPGZS¾T‘V_DGTWB=fYHKBYg‰DGFIT}Z$XQV_HKZ[H\tWTMJ|DjXQDGT)Z[TWB["\ C 465^] : ¾&_ 5^] :ÜŽ 5a4Á5^] :l: G 5 ¤QÅ :VWX©YaV=Y 5a465^] :l: HKJ{XdBHKB„DGT)g>T‘PqzC¦dXdaKiYTpf cuiYBIhWDGHKNdB¥DGF=X;DSXQJqJqH\gdBIJXL'FYTWPGT465^] : k_lOFIT0H\fYTpX HKJODGFIT)B[DGN]Z$XQV_HKZ[H\tWT'DGFYTLT)HKg>F„DODGN]TpXdhjF6a\HmDGTWPjXQaDGFITycuiYBIhWDGHKN>B FIXdJODGN]`rTDGNQDjXdarLOTWH\gdF„DxNdc~DGFIT}aKHmDGTWPjXQa\J)kt}NpLT)¦§TWPp“J|DjX)n_J'h)N>BYh)HKJqT>kš /P›¥/Dœ ! ,.-1û/ ! . š ŸŸÎ ¡ - ¢ Ÿ !C -ú§qrC W~ë£ G Ô b=9 Ô ÷h1jDLIµ ¡ µ ²\­ L ± Ê ® ª=¨ ±œ² ©dª ¨ ¦ 5 ˆ : ²’¸ ¨G©dªr¨ ²u¸ µoC W GC W~ëF¬ GC Wƒë´ì~ëF£ GŽM9cb´b;qG?O›vTWD `rTUDGFYTUB iIZ`rT‘P3Ndc'h)NdZ[^rN>BYT)B„DGJ]HKB†DGFYT[h)N>B_e=gdiYzPjX;DGHKN>BEZ[N fYTWa~XQB=fU6DGFITMB iIZ‰`rTWP'NdcNd^YDGHKZ[HKtpXQDGHKNdBShWPGHmDGTWPGH\X_k+lOFYT LT)HKg>F„DSc’iIBIh‘DGH\NdB ¨ ¦ 5 ˆ : H\Jh)aKTpXQPGamnÄh)NdZ[^IiYDjXQÌaKT·H\BÄ^rNdaKn_BYN>Z[H\XdaDGHKZ[T>k§lOFITyZ$XQV_HKZiYZ ¦>XQaKiIT'Ndc {C W~ëpì GC W~ëpì~ë¬ GHKJ3XQamLxX)n_J3J|DqPGH\h‘DGaKn‚aKT)JqJ0DGF=XdB Œ ¦ Œ L'FITWB ß ¼>kvlOF iIJ)“rLThpXQBXQJqJqHKg>B·XdBEiY^I^rTWP0`rN>iYB=f¤'¦¥¨„kr@ c Ž ¼>“IDGFIT)B ¨ ¦ 5 ˆ :ê SXdBIfC ì GC ì~ëF£ GLT3hpXdBiIJqTH¤'XdJ0X`rNdiIB=f6JqN ¨ ¦ 5 ˆ : H\J'h)NdBIh)HKJqT>kC ì~ë¬ GcuNda\aKNpL'HKBIg$^YPGNdgdPjXQZS¾W 7 ì 7 £ 7 ¬ GI@ CV/W"X©YZVIY [9\ C YZ« 5^] : ¾©{§¦ 5^] : G@‡B$XdfIfYHmDGHKN>Bv“„aKTWDxX}c’iIBYhWDGHKN>BKÐE¾'F€DDGN‚`rT6XdỲaKT{DGN‚iIJqT6X‚Z[NdPGT$g>T)BYTWPjXdaOLT)HKg>F„Dc’iIBYhWDGHKN>B~k©lOFIHKJUhpXQB`rTXdhjFIHKT)¦§T)f·`„n‚XQa\aKNpL'HKBIg‚XQB nSa\HmDGTWPjXQaKJ DGN{`rTHKB€X{hWPGHmDGTWPGHKN>B†XdBIff_TWe=BYTpf[hpXQPGT‘cuiIaKamn6DGNT)BYJqiYPGT0DGFIXQDODGFYTMh)NdZ[^IaKTWDGT0LT)HKg>F„DxcuiYBIhWDGHKNdBDGFIT3iYJqTWP'LxXdB„DGJ'DGN[F=Xp¦§T}DGFYT3h)N>Z[^rNdBIT)B„D ¬ HKBSDGFIT3h)NdBYeIg>iYPjX;DGHKN>BlOFYTh)NdBYeIg>iYPjX;DGHKN>B·^YPGN>ỲaKT)ZbNQcxX{—}˜}3šQ›~HKB iYVEJ|n_J|DGT)Z F=XQJMD‡LNlOFIT3iYBIH\º„iIT}Nd^YDGHKZ$Xdavh)NdBYe=gdiYPjX;DGH\NdBSHKJ'BINpL C Wƒë´ì~ë¬ G kHKZ[^rNQPqDjXdB„D'h‘FIXQPjXQhWDGTWPGHKJ|DGHKh)J)¾¼dkMDGFITyh)N>B_e=gdiYPjXQDGHKNdB{Z[N f_T)a=HKJOa\XQPGgdT3XdBIf[DGFYTWPGT0XQPGT}iYJqi=XQa\amn$F iIB_zf_PGTpf_JxNdc^IXdhjR>XQg>T)J'HKBSXhWN>BYeIg>i_PjXQDGHKN>BvÁrXdBIf›¥/p-3- ! -.iû/ ! . š Ÿ#Î ¡ - ¢ Ÿ !‡ -yÈü ! Ÿ š1ý!ýKþJ|DjXQDGT)Z[TWB DGJ6Ndc}›k'lOFIT‚cuiYBIhWDGHKN>BYJEXQPGT†fYTWeIBITpfHKB¥DGTWPGZ[J6Ndc¤„kMDGFITU—}˜}3šQ›~HKB iYVEHKJ}c–PGT)TUJqNQc’D‡LOXQPGT[JqNX6h)NdBYeIg>iYPjX;DGHKN>B€L'HmDGF†X…oT0hpXdB{fYTWeIBITyh)N>BYh)HKJqTMN>^_DGHKZ[H\t)XQDGHKN>B6cuiIBYhWDGHKN>BYJOiIJqHKBIg]Z$XQV_HKZ[HKt)TF iIB=f PGTpf†^IXdhjR>XQg>T)JUFIXdJ‰T)JqJqT)B„DGH\XdaKamnýDGFYT$JGXdZ[T6h)N>J|DUDGFIXdBAN>BYTL'HmDGFEX‰DGFINdiIJGXQB=f{^IXdhjR>XQg>T)J)kZ$X)n{`rT§T)hpXdiYJqT‰NQcDGFITMeIPGJ|D0^YPGNd^rTWPqD‡n„“Yh)NdBYe=gdiYPGHKBIg[DGFYT3J|nYJ|DGTWZ¦>TWPqnEDGTpfYHKNdiIJ]XdBIf†HmD‰Z$X)nEDjXQR§T[Z$XdB„n‚FINdiYPGJ3HmcxDGFITiIJqTWP]F=XQJ3DGNJqTWa\TWhWD^IXdhjR>XQg>T)J6N>BYT·XQDX†DGH\Z[TdkOlOFYH\J{h)N>iYa\f¥`rT‚JqH\Z[^YaKHKeITpf¥`„nhWN>BIJ|DqPGiYhWDGHKBIg€X‚DGN„NdaxDGF=XQD[XdaKaKN;L'JUDGFYTiYJqTWPUDGN·J|DjXQDGTHKBýg>T)BYTWPjXda…oT}L'HKaKa~fYTWeIBIT}DGFYT}LOT)HKgdF D'c’iIBIh‘DGH\NdBHKJ'JqiIhjF{LOXpn$DGFIXQDxDGFIT}Z[NdPGTDGT‘PGZ[J'L'FIXQD}FIT3NdP}JqFIT3LxXQB„DGJ0DGN$fYNUL'HmDGFSDGFYT]J|n_J|DGT)ZSk=lOFIT3DGN„N>aLN>iYa–fDGFYT)BEXQiYDGN>Z$X;DGHKhpXdaKamnSgdT)BITWPjX;DGT]XUh)N>B_e=g>i_PjXQDGHKN>BEJGX;DGHKJ|c’n_HKBIgDGFYTEiIJqTWP¡J$BITWTpfYJ)k§…oTEhpXQB¥fYN†DGFYHKJ6`„n fYT‘e=BIHKBYgoh)N>aKaKT)hWDGHKNdBIJNQcN>`~Q|T)h‘DGJ Ë “ 898"8 “ ¦ XQPGT0DqPGiYT0HKB6X J|DjXdÌaKT0Z[N fYT)aYNdcƒDGFYT£0›E^YPGNdzgdPjXQZS“pDGFIT.FIHKg>FYTWP1LOTWH\gdF„DHKD©XdJqJqHKg>BYJ1DGNyDGFYTh)NQPqPGT)Jq^rN>BIfYHKBIgyh)N>B_e=gQziYPjX;DGH\NdB~kY@Cc1DGFYTWPGT3X;PGT3Z[NdPGT}DGFIXdBNdBIT3hWPGHmDGTWPGH\X “IDGFIT‘nX;PGT3NdPjf_TWPGTpfPGTWa–X;DGTpf ^=XdhjRdXdg>TWJ)“&LY© Ģ± à ¯ © ¬ \µ ¸ “;DGF=X;D1hpXQB‰`rT§JqT)aKT)hWDGTpf HKBXdfIf_HKDGHKNdBDGN]BINQPGZ$Xdar^IXdhjR>XQg>T)J)kYlOFIT}^YPGNdeIaKT)JxhpXdB6`rTMf_TWe=BYTpf$T)HmDGFITWPx`„nUDGFYTh‘PGTpXQDGNQPGJ1Ndc_DGFIT§fYHKJ|DqPGHKÌi_DGH\NdB‰NQP1`„n XxaKN„hpXda J|n_J|DGT)Z¤X>f_Z[H\BYHKJ|DqPjXQDGNdPpkHKBSXdBXdJqh)TWB=fYHKBYgNdPjf_TWP'Ndc1H\Z[^rNQPqDjXdBYh)T3XdBIf$DGFYTMZ[NdPGT0HKZ[^rNdPqDjXdB„DT)h)XdiIJqT}NdcƒDGFYTMJqT)h)NdB=f$^YPGNd^rTWPqD‡n$NQcƒDGFIT}^YPGN>ỲaKT)ZÈf_N>Z$XdHKBv“_LTXUhWPGHmDGTWPGHKN>BEHKJ)“=DGFYT3FIHKg>FYTWP0LT)HKg>F„D0HKD}XdJqJqHKgdBIJ0DGNUXUh)N>B_e=g>i_PjXQDGHKN>BvkLN>iYa–f‚Ndc–DGT)B‚LxXdB„DMDGN6HKBIh)aKiIfYT^rNQDGT)B„DGH\XdaKamn‚iIJqTWc’iIa^=XQh‘RdXdgdT)JMHKB„DGN…oTXdaKJqNEXdaKaKNpL DGFITh‘PGHKDGT‘PGH–X6DGN{`rT[f_TWe=BYTpf‚f_n_B=XQZ[HKhpXdaKamn„“vfYi_PGH\BYgDGFYT$h)N>B_e=g>i_PjXQDGHKN>BAHmcyDGFITWPGT$HKJT)BYN>iYg>FýfYHKJqR†Jq^IXdh)T{Xp¦>XQHKa–XQÌaKT{c’NdPDGFYT)ZSkp@CBIJ|DjXdaKaKHKBIg'DGFIT)Z XQD1DGFYTJGXQZ[T.DGHKZ[T§L'FYT)B3DGFIT§NdDGFIT‘P©J|n_J|DGT)Z¨ ¦ 5 ˆ : ²u¸ ´„µ ¬ ªrµG´ °d¸ Ê)©duK© ¡¸©HKJ'h)NdBYe=gdiYPGTpf6JGXp¦§T)JxDGHKZ[T3XdBIf{DqPGN>iYÌaKTMHKBDGFIT}a\NdBIgUPGiYB~k…oTf_TWe=BYT©DGFITN>^_DGH\Z[HKtpX;DGHKN>B3hWPGHmDGTWPGH\XxcuNdP~DGFITJqHKZ[^IaKHme=Tpf0•MT)ÌH\XQBf_T)a+iIJqHKBIg‰DGFIT}c’N>aKaKN;L'HKBYg{^_PGH\BYh)HK^IaKT)J)¾hWN>BYeIg>i_PjXQDGHKN>BSZ[N¼dk3Z$XQV_HKZ[HKt)TyDGFYTMB iIZ‰`rTWPNQc©^=XQh‘RdXdgdT)Jx`rT)aKN>BYg>HKBIg‰DGNUX‰FYN>J|Dx^_PGNdzŒ¢ {e=aKT>ÁÅ>Å

…oTUh)XdBoJqT)T[DGFIXQD3DGFITWJqT[hWPGHmDGTWPGH\XSJqN>Z[TWDGHKZ[T)J3HKZ[^rN>JqT[hWN>B(IHKhWDGHKBIgHKBYzfYT)Z$XQB=f_J)kFÒYNdP0TWVYXdZ[^IaKT>“YHmD}HKJy^rN>JqJqHKÌaKT3DGF=X;D'DGFIT3FINdJ|D}^_PGNdeIa\TX{^IXdhjR>XQg>TDGFIXQD3HKJ3HKB†h)NdB(IH\h‘D3L'HKDGF€X{J|DjXQB=fYXQPjf€^IXdhjR>XQg>Th)aKi=f_T)JNdPOPGTWh)N>Z[Z[T)BIfYTpfU^IXdhjR>XQg>T)JOXdB=f$N>BYT/©»ª W~«'¬TW&­±¬ ^=XdhjRdXdg>T0N;¦§TWP'XQB n NdBIh)TW^YDGi=XQaKaKn„“Qf_iYPGHKBIg0X'h)N>B_e=g>i_PjXQDGHKN>B DjXdJqRMLTeIPGJ|D1X>fYf]^IXdhjR zHKBIgUZ$X;VYHKZ[HKt)T0J|DjXQDGT)Z[T)B„DGJ)¾X§\ C Ya«T² §´³ ¾ Y © ¿’­±\"£ ® VHV/\'«'¬T\"¬F² §´³ GVW"X©YZVIY["\ C Ya«T² §´³ ¾¡©»ª W~«'¬TW&­±¬F² §´³ GVWX©YaV=Y["\ C Ya«T² §´³ ¾ YZ«¿ © \§¯ \"£ ª \9¬&¿O ®§©»ª ¿’¢§­ ® ¼´¯ \§² §´³ GVWX©YaV=Y5 ¤§ :Z$XQV_HKZ[HKt)T3J|DjXQDGTWZ[T)B„DGJ0X;PGTXQg§XQH\B‚HKB‚XdB‚XQJqh)T)BIfYHKBIg[NQPjfYTWP0NdclOFITYZ«¿ © \§¯ \9£ ª \"¬&¿’ ®§©»ª ¿’¢&­ ® ¼p¯ \ HKJ©DqPGiITL'FYT)BHKZ[^rNdPqDjXdBYh)T>kdlOFITx^_PGTpfYHKhpX;DGTHKBIh)aKiIfYTpfMFYN>J|D1^_PGNdeIa\T§XdBIfDGFIT^=XQh‘RdXdgdT§HKB]º„iIT)J|DGHKNdB3`rT)aKN>BIgdJƒDGNyXdBY © ¿’­±\"£ ® V V\§«'¬T\9¬ H\J0fYT‘e=BIT)f{XQJ'c’N>aKaKNpL'J)¾DGFITM^_PGTpfYHKhpX;DGT© ¿’­±\"£ ® VHV/\'«'¬T\"¬ 5l§;¾ : @ ­±\"£ ® V V\§«'¬ © 5l§´½ 7 §;¾ : 7 YZ« 5l§´½ : 8 5J :YÓ!ÔTÕ g6e’8e±b g¥DàÖ ² À µ‘ª °6­d¯ © ® ª=´†¨G©dª ¬ƒ­d® ¯q°d±œ² ©Qª¥³[©p´§µW6{=} ° ª=´Ô b=9 Ô ÷Úá•jDLIµ à ¯ ©  \µ‘³KE!47G6I!,B-L/C172'):3C4760&H80):/!1M;z{=} 7 J=«C¨j©Q³}Ãr\µ ± µo ²’¸ONSm!ng6e’8e±b g¥PRQjª ± LIµ0à ¯ ©  \µ‘³SE!4!GH6I!,B-0/!172'):3C4!60&98)+/C1,UTV)W8X,Ó!ÔTÕ7 7 Ð 7[ = ¡ µ °d¯ µ ­d² À µ‘ª °o­d¯ © ® ªr´¥¨G©dª ¬1­d® ¯q°Q±œ² ©dªTYGH):35X8Z;z{=}³U©p´„µWT{=} Û ° ¸ µ ±Ô b=9 Ô ÷ ä\Q’Ê ± LIµ ¡ µ ²\­ L ± Ê ® ª=¨ ±œ² ©dªŒÐ ²u¸ ¨G©dªr¨ ²’¸ µ Û ± LIµ6à ¯ ©  «7 7 Ð 7_[ = ²u¸\µ‘³]E!4!GH6I!,B-0/!172'):3C4!60&98)+/C1,UTV)W8X,^TYG)+35X8Z;»{=}«C¨G©d³}Ã=\µ ± µo N|mKng6e’8e±b gÄh9`•Ö ² À µ‘ª °E­d¯ © ® ª=ś¨j©Qª ¬1­d® ¯|°d±œ² ©dª¥³U©p´„µW2{=} Û °Ó!ÔTÕµ ± £©|Ê ® ¸ µ Ā¯ µ’‘ ® ²u¯ µ‘³$µ‘ª ±œ¸ Û ° ªr´ °ã¡ µ ²\­ L ± Ê ® ªr¨ ±œ² ©QªéÐ Û ± LIµ¸¯ ©  \µ‘³ ©|Ê ¬ ªr´ ² ª ­†° ¨G©dª ¬ƒ­d®_¯|°d±œ² ©dª ˆ Ģ® ÖL ± L °d± ˆK‹Œ{=} ”êr´µˆ ²’¸ ©‘à ±œ² ³ ° ¡²u± L ¯ µ ¸ ÃYµG¨ ±[± ©—Ð ²’¸ ¨ ° u\µq´/!aH8)+b§&C(c,B-0/!1,°7 7 Ð7=§o2')+354760&98):/!1k©w0JDGFYH\J‰HKJ$XdBAHKBIJ|DjXdBYh)TNQcXQB=f{LT F=Xp¦§TMDGN[HKJqJqiIT aKN>g Œ ¤ ¦ ¨ Ž ¦ º„iITWPGHKT)JyJqNUDGFIT ^_PGN>ÌaKT)Ẑ HKJX;D Xp¦dXdHKa\XdỲa\Tp'qqrufufurfyf|Ht'x_}0~'€''xkrrrŽM9cb´b;qG?1lOFYT}DGFITWNdPGT)ZÈc’N>aKaKN;L'JMfYHmPGT)hWDGamn$c’PGNdZàÆ©PGN>^rNdJqHmDGH\NdBo¼>kwriIZ‰`rTWPMNQc'^=XQh‘RdXdgdT)JMDGF=X;D‰FIXp¦§TB[Z$XdR>T)JHKD.HKZ[^rN>JqJqHKỲa\TxDGN3JGX;DGH\J|c–nDGFITMJqTWh)N>BIfhWPGHmDGTWPGHKN>Bvk…†T}NQPjfYTWPxDGFYT}hWPGHmDGTWPGH\X‰JqN‰DGF=XQDLOTM^_PGTWcuTWPyXdfIf_H\BYg‰NdBITM^IXdhjR>XQg>TŽM9cb´b;qG?1lOFYT}DGFITWNdPGT)ZÈc’N>aKaKN;L'J0c’PGN>Z Æ©PGN>^rNdJqHmDGH\NdBo¼>kc’PGNdZ DGFYT$FIN>J|D‰^YPGNQe=aKT[N;¦§TWPXdB„n€B_iYZ`rTWP NQc ©»ª WT«'¬TW&­±¬ ^IXdhjR>XQg>T)JB iIZ`rT‘PMNdcxPGTWh)N>Z[Z[T)BIfYTpfE^IXdhjR>XQg>T)J)kƒlOFIHKJ]H\J `„n‚BINZ[TpXdBYJMDGFITN>BYaKn6^rNdJqJqH\ỲaKT]NQPjfYTWPGHKBYg[Ndc1DGFYTMhWPGHmDGTWPGH\X_kªr´ °!¡ µ ²\­ L ± [ · Ù ° ª=´ ± LIµU© £¢ µq¨ ±O²u¸M± © ¬ ªr´ ° ¨G©dª ¬1­d® ¯q°Q±œ² ©dª°Ģ® ÖL ± L °d± ˆ£‹U{=}æ”U ° ªr´Ð 5 ˆ : è [ oˆXdgdT)J3DGF=XQD3XQPGTUBYT)TpfYT)f‚DGN6JGXQDGHKJ|c’n·DGFIT‰iIJqTWP}PGTpº„iIHmPGT)Z[T)B„DGJ)k+˜}T‘V_Dp“©|Ê ® ¸ µ ¯'¯ µl‘ ® ²u¯ µ‘³[µ‘ª ±œ¸ Û °=¡ µ ²\­ L ± Ê ® ª=¨ ±œ² ©dªfYf^=XQh‘RdXdgdT)J0DGFIXQD0XQPGT HKBSDGFIT3FYN>J|D0^YPGNQe=aKT]XdB=ffYN[BINQDyh)N>B_z(=HKhWD©L'HmDGF^IXdhjR>XQg>T)J1DGFIXQD.X;PGT'XdamPGTpX>f n]H\B]DGFIT§h)N>B_e=g>i_PjXQDGHKN>Bvk§w'c’DGTWPDGF=X;Dp“~LT{XdfIf€XdaKaOJ|DjXdBIfIX;Pjf†^=XQh‘RdXdgdT)J3DGF=XQD‰f_NSBINQD‰h)XdiIJqT$^_PGN>ỲzaKT)Z[J)kpÒ1HKB=XdaKamn„“+LOTDqPqnEDGN$e=BIf€X$Z$XQV_HKZ$Xda©JqT‘D3Ndcx^IXdhjR>XQg>T)J0DGF=XQDn†HKB†DGFYTUh)NdBYe=gdiYPjX;DGH\NdBsXdBIfXQPGTUPGT)hWN>Z[Z[T)BIfYTpfE`„n‚DGFIN>JqTUXdamPGTpX>fX>fYf6DGFITWZÈDGNHmDpklOFYTx•MT)ỲH–XQBLOTWH\gdF„D§c’iIBIh‘DGH\NdB[hpXdB`rT0f_TWe=BYTpf]L'HmDGFDGFYTOcuNda\aKNpLxzŽM9cb´b;qG?ÒIN>aKaKNpL'J{f_HmPGT)hWDGamnAc’PGN>ZlOFIT)NQPGT)Z J XQB=fsDGFITcuXdhWD[DGFIXQDLT‰h)XdB‚g>iYT)JqJ}DGFIT3LT)HKg>F„D3NdcX[h)N>B_e=gdiYPjXQDGHKNdB€XQB=fE¦§TWPGHmc–nEHmDMHKB·X^rNdamnYBYN>Z[H\XdarDGHKZ[TM`„n6•MTWeIBIHmDGHKN>B ` k+ § Ì ¡ Ÿ_,©Ÿ !C -y,|x + Ì x‡/! ! Ÿ %JqTWDxNQcƒh)NdBYeIg>iYPjX;DGHKN>B{DjXQJqR JxXdBIf6XQB=X;z@‡B[DGFIHKJOJqTWhWDGHKN>B$LOT3f_TWe=BYT}XPGT)JqiYaKDGJamnYtWTODGFIT)HmPh)NdZ[^IiYDjX;DGHKN>B=XQaYhWN>Z[^IaKTWV_HmDGHKT)J)k>lOFITOh)NdZ[^IaKTWV_HmD‡nJqiI^Y^rN>JqTMDGF=X;D'DGFITMh)NdBYeIg>iYPjX;DGHKN>BEZ[N fYTWa\JyX;PGT fYTWeIBITpf$L'HKDGF0›Ìi_DxDGFIT}PGT)JqiYamDGJygdT)BIT‘PjXdaKHKt)T]DGN‰NdDGFYTWP0ÿSŽ}z h)N>Z[^Ya\T‘DGTMcuNdPGZ$XQaKH\JqZ[J)kLT)HKg>F„D{Ndc]XdB¥Nd^YDGHKZ$Xdayh)NdBYe=gdiYPjX;DGH\NdB¥`„n¥iYJqH\BYg ÂW² ª °Q¯ N ¸ µ °d¯ ÖL„k…†TeIPGJ|D6hjFIT)hjRsL'FITWDGFYTWP$DGFITWPGTET‘VYHKJ|D{X†JqiYHKDjXQÌaKTEh)NdBYe=gdiYPjX;DGH\NdBc–PGT)T.h)N>B_e=g>i_PjXQDGHKN>B Z[N f_T)aœ“…†TJqFINpL†DGFIXQD~HKc_LOT.F=Xp¦§T.Xx¦dXQPGH\XdỲa\T‘zDGFIT'¦dXdaKH\fYHmD‡nNdc~XMh)N>B_e=gdiYPjXQDGHKNdB6h)XdB$`rT'h‘FYT)h‘R>TpfHKB$X3^rN>amn_BIN>Z[H\XQaDGHKZ[TUL'HKDGFoPGTWJq^rT)hWDDGNSDGFYT$JqH\tWT{NQcxDGFIT$Z[N fYT)aœk1lOFIT$^YPGNdÌaKT)Z NdcE!47G6I!,.-0/C172')+354760&98):/!1,^TY)+8X,^TYGH):35X8ƒ“dHmDh)XdBU`rTyfYNdBITxHKBUh)NdBYzJ|DjXQB„DxDGH\Z[T}iIJqHKBIgDGFYTMNdPjXQh)aKT>kZ[T)B„DGJƒHKJ'ÿSŽ}z h)N>Z[^YaKTWDGTXQJ©HKJ1DGFIT.^YPGN>ỲaKT)Z NdcYe=BIfYHKBIgyX0JqiYHmDjXdÌaKT˜}NpL3“§fYT)^rT)BIfYHKBIg3NdBUDGFIT'XQBIJ|LOT‘PLOTyT)HmDGFIT‘PhjFIT)hjR L'FITWDGFYTWP§DGFYTe=BIfYHKBIg€X·JqiYHmDjXdÌaKTShWN>BYeIg>i_PjXQDGHKN>B g>HK¦§T)B X€JqTWDUNdcMiYJqTWP[PGTpº„iIHmPGTWzLOT)HKg>F„D HKJMN;¦§TWP=¤ ¦&¨9e Œ NdP3N;¦§T‘P ¤ ¦&¨'e Ë Ç ¤ ¦©¨fe Œ kvlOF iIJ)“Nd^YDGHKZiYẐLOT)HKg>F„DHKBUT)XdhjF[J|DGT)^LOT'FIXdaK¦§TxDGFITx^rNdJqJqH\ỲaKT'PjXQBIgdT0NQcrDGFITxN>^_DGHKZ$Xdah)N>B_e=gdiYPjXQDGHKNdB€L'HmDGFoX6Jq^rT)h)Hme=hLT)HKg>F„D HmcODGFIT]LOT)HKgdF D3c’iIBYhWDGHKN>BÈÐHKJ‰h)NdBIh)HKJqT>kƒ…oT[JqFINpL£DGF=X;D]DGFYT[^YPGNdÌaKT)ZûNdcxeIB=f_H\BYgEXdB†N>^YDGHKZ$XQah)N>B_e=gdiYPjXQDGHKNdB6HKJ§H\B6‹Œ)yŽk§@CD§H\J§BINQDh)aKTpX;POL'FIT‘DGFITWP.DGFIT'^YPGNdÌaKT)ZHKJ0XQaKJqN6‹UŒ)'Ž}zChWN>Z[^IaKTWDGTdkHKBS‹UŒ)'ŽkÌi_D.DGFYTWnXdaKJqN‰FYN>a\fUHmD§DGFYT'JqH\tWT0NQcrDGFIT'HKBIJ|DjXdB„DGH\XQDGHKNdB6NQc+DGFIT'Z[N fYT)aHKJy^rNdamnYBYN>Z[H\Xdaœ“_L'FIHKhjFSHKJ'DqPGiYTMcuNQP0Z[NdJ|D'^YPjXQhWDGHKhpXda~hpXdJqT)J)kg6e–8efb g#"àÖ ² À µ‘ª °{­d¯ © ® ª=´€¨G©dª ¬1­d® ¯q°Q±œ² ©dª¥³U©p´„µWÁ{=}ÓKÔTÕž Ì x‡/ /1-Ÿ_,©Ÿ !‡ -È,.- ihkj ,Üx ¡ ,©Ÿ !C -gfYT)aYF=XdJ`rT)T)B[HKZ[^IaKT)Z[T)B„DGTpfXdJxXQBlOFYT0•}T)ÌH\XdB$h)NdBYeIg>iYPjX;DGHKN>B6Z[N^_PGN>gdPjXQZiIJqHKBIgDGFYT?l0bO/!*!G(AmMJ|nYJ|DGTWZû» %p½©f_T)¦§T)amzT‘V_DGTWB=fYT)f{aKN>gdH\hlOFYT§PGT)JqiYamDGJ©XQPGTOJ|DjX;DGTpf3cuNdP¦dXQPGH\XQÌaKTWzõc’PGT)Th)N>B_e=g>i_PjXQDGHKN>B]Z[N fYTWa\J° ªr´Nd^rTpfSHKBSDGFIT]›ƒXQ`rNdPjX;DGNdPqnSc’NdP lOFYT)NdPGTWDGHKhpXQa N>Z[^YiYDGTWPI_h)HKT)BYh)T HKB° ¨G©dª ¬ƒ­d®_¯|°d±œ² ©dªKˆ Û ± LYµxà ¯ ©  \µ‘³ ©|Ê3ÖLIµq¨ ¹Q² ª ­ ¡ LIµ ± LYµ ¯ ˆ‹{=} ²’¸t0T)aKJqHKBIR H00BIHK¦§TWPGJqHmDCn NQc]lƒT)hjFIBYN>aKN>gQn„kOlOFYTnl0bo/!*CGH(mJ|n_J|DGT)ZHKJ° u\µq´%$'&!()+*!,.-0/!1!2')+354760&98):/!1='o¨Ô bI9 Ô ÷ÚÃwjDLIµ]à ¯ ©  \µ‘³@$'&!(A):*7,B-0/!172'):354760&98)+/C1

fYT)a1L'HmDGF·^YPGTWc’TWPGT)BIhWT)JMLxXQJlOFYT‰c’iIaKa•MT)ÌH\XQB€h)NdBYeIg>iYPjX;DGHKN>B·Z[NZ$XdHKBE•MTWÌH\XdB·fYHKJ|DqPGHKÌi_DGHKN>Bs¤ kK¼DGT)J|DGTpfSiYJqH\BYg6XdhWDGiIXdafIX;DjX[NdcDGFITDGJvLOTWPGTg>T)B_zL'HmDGF¡¤&¤§%&%}f_HmÇ+TWPGT)B„D©^=XQh‘RdXdgdT)J)kdlOFITOiYJqTWP©PGTpº„iIHmPGT)Z[TWB¨ ÆU¥Z$XdHKB{Z[T)Z[NdPqn„k lOFYTMiIJqT)f{JqNdc–D‡LOXQPGT ¦§TWPGJqHKN>BYJxLOTWPGTL'HmDGF¤&%XdB=f crH†A‡Hxc€'ƒˆ‰v.ŠŠ‰v^‹'Œ kx}0~Af€''xƒf„5vB„f…JqFINpL'BAXQPGT{Xp¦§TWPjXQg>T)J‰NQ¦>TWP{¼"&SPGiIBYJ)k2 T)^=X;PjXQDGT[e=gdiYPGT)J‰XQPGT6^YPGTWzëƒÛ|Ò á ÚrØ)Ö æ ÎC“’ÏB” å æ Öjá0“–Ï•” Ó§Ñ§Ï æ Ö‘á0“–Ï•” ’ å æ Ö’÷ á ˜¡˜ ÷ á š2áð>› –2ïñpñ 2 á › 2 ÷ á2p2 2áñ¡› ÷ ˜œž¡œžŸ¡ ÷ á2p2 ÷ á ˜2 2 áñ)𠘡š2¦ iIT)BYg>J|DXdB=ft}T)HKBYPGHKhjFE» J ½IDGN„NdRUXQBINdDGFYTWP.PGN>iYDGT'`„n]^YPGNd^rN>JqHKBIg]X NdBIh)TW^YDGi=XQaKaKn]DGFITOXd^I^_PGN§XQh‘FUNQcDYXQÌHKBUXQB=ff_i=X;DGTµ_hjFIN„NdayHKB N>ZUz^YiYDGTWPI_hWH\TWBIh)TXdB=f­¤BIgdH\BYT)TWPGHKBIg5t}T ¤ : kr…oT LON>iYa\f·XQaKJqNaKHKR§T5ä§Õ‡Î£µÜ;Ö Ö‡àLµ ²¡²_·Z·Z·'áç§Í ê Ðæ ÑIáØpÕCÝf¸xá>Ã_Æ•À ¾ ÀÃ9¿BÀ§¡ÃÎÍL.Ä>Â+¿ ¼Z¾ .Ä ¾ Ÿ¡ÏÐÏÐÂWÃAÄ Þdà æ ÝpÍGÏ 2 ñ ñ_— 2 ñ š ñ Þ>ådÍ æ Ö Ö‡ÎmÍpÞÌ› ¯ÒÑÍjÕCѧÍGÕ1è§áAÓpä§ÍGѧÝpÏ Ö æ ѧç¹ÐmÛ|Ü æ ÍGÎ_̧ÍGÐmѧÕCÐmÛ|ÜIáYÓ§ÏCÐmѧÝxÕ‡ÍGÏCØpä§Õ‡ÛGÍ ê„æ Îö®¾ Ÿ•ÜcÜ9 Â:¿BŸ¡œ£Â+¡Ã'Å Þ_à æ ÝpÍGÏ ïpño—]ï š>Þ_ìÛqÖ‡Ø ê ÍGÕ 2–¡–¡š>᜞À_ÏÚÅÃ9Ÿ¡ Ì ¡ÏéÜ9 ÀBê>ÂWœ£Ø áÌò ÉAó ´éḾ´ó~ëƒÕ‡ÍGÏCÏ‘Þ 2–¡–¡–>៕ÜcÜ9 Â:¿BŸ¡œ£Â+¡Ã'Å Þ_à æ ÝpÍGÏ ð;÷o— ð –>Þ_ìÛqÖ‡Ø ê ÍGÕ 2–¡–¡š>áíoÅ£ÜAÀB¿œ£ÅY^ÆJöoÀB¿_ Ÿ ¾ Ÿ¡œ£ÂW÷À?ÍLŸ¡ÃAÄ>èŸÄ>À_Å áƒådà>Õ‡ÐmѧÝpÍGÕCö:ºƒÍGÕ‡Îæ ݧÞÓ æ ÑQä æ Õ ×®2p2•¯ íáÑÐmÍGÎmÐmÑ§Ý æMæ ѧçV°0á ådÛ|Ü>Õ‡ÍGÐê ÍjÕjá~â1ØpÑ>ú„Ýpä§Õ æ Ö‡ÐmØpÑ>öuç§ÍGχÐmÝpÑUà§ÕCØ ê ÎmÍGã+ - ¢ x ¡ y !‡ -y ,.- Î ¡ Ÿ ¡0& /ãû .&L£C§…†T^_PGT)JqT)B„DGTpf·X{cuNQPGZ$Xda.fYTWeIBIHmDGHKN>B‚cuNQP‰Nd^YDGHKZ$Xdah)NdBYeIg>iYPjX;DGHKN>BIJ)kHKZ[^rNdJqT)J'X^YPGT‘cuTWPGT)BYh)TMPGT)a\XQDGHKNdBEN>B{DGFYTMJqTWDyNdc©XdaKaƒh)NdBYeIg>iYPjX;DGHKN>BIJ)kTWPjXQDGT)f`„n‰hjFIN„NdJqHKBIg3PjXdBIfYN>Z[amn‰X0eYVYT)f‰B iIZ‰`rTWP©Ndc+^IXdhjR>XQg>T)J)k§lOFITlOFYT'`=XdJqHKh}Xd^I^_PGN§XQh‘F$HKJ§DGN f_TWe=BYT0XQB$N>^YDGHKZ[HKtpX;DGH\NdB[cuiIBYhWDGHKN>BUDGFIXQDB iIZ`rT‘P$Ndc iIJqT‘P{PGTpº„iYHKPGTWZ[T)B„DGJ[¦>X;PGH\T)f`rTWD‡LT)T)B‰>‚I¼§_k'@‡BX>f_zlOFYT[N>^_DGH\Z$XQah)N>B_e=g>i_PjXQDGHKN>BYJ]XQPGT$Z[HKBIHKZ$Xda©T)aKT)Z[TWB DGJ3NQcxDGFIHKJMPGTWzfYHmDGHKN>Bv“X‚FINdJ|D[^YPGNQe=aKTL'HmDGF Å&€^IXdhjR>XQg>T)J‰LxXdJ[h‘PGTpXQDGTpf XdBIfýHKBYza\X;DGH\NdB~k.…oTfYTWeIBITpfoDGFIT{h)a\XdJqJ$NdcMh)N>BYh)HKJqTLOT)HKgdF D[c’iIBYhWDGHKN>BIJUc’NdPh)aKi=f_Tpf¥HKBDGFITEh)NdBYeIg>iYPjX;DGHKN>B~kOlOFITEDGT)J|DGJ$LOTWPGTEPGiYBiIBIfYTWP6•MTWzÌH\XdB—}˜}Mšd›vH\B i_V!¤ kK¼3NdBX ` %§Æt}tM@CB„DGT)á Æ1T)B„DGHKiIZ£@q@q@§J|n_J|DGT)ZL'FYHKh‘F6DGFIT3N>^_DGHKZ[H\t)XQDGHKN>BS^_PGN>Ỳa\TWẐ H\J'HKBE‹ Œ yŽkDGT)f{X3PGiIaKTWz `=XQJqTpf{a\XQBIg>iIXdgdT=0›SDGF=XQDOhpXdB{`rT}iIJqT)f…oT0^YPGT)JqTWBfYT)aKJ0XdBIfJqFINpLOT)fSFINpL Nd^YDGHKZ[HKtpXQDGHKNdBDGNUfYTWeIBIT3h)NdBYe=gdiYPjX;DGH\NdBEZ[Nc’iIBYhWDGHKN>BIJ'hpXQBS`rT3f_TWe=BYTpf6L'HmDGFSHmDpk…oT§cuNdPGZ$XQaKH\tWTpf[XMJqiIỲJqTWDNdcrDGFYTxh)N>B_e=g>i_PjXQDGHKN>B[Z$XQB=XQg>T)Z[T)B„D©NQclOFYT6PGTWJqiIamDGJNQc0DGFYT$DGTWJ|DGJUXQPGT{JqFINpL'BAHKB lƒXdÌaKT‚¼>k.lOFYT6DGHKZ[T)JDGFYTM•MT)ỲH\XdB‚—}˜03šd›vHKB_i_V6J|nYJ|DGTWZXdB=ffYTWeIBITpf{Xh)N>BYh)HKJqT3LOT)HKg>F„DJqT)B„DGTpf‰c’NdP§JGXQDGHKJ|erXQÌaKTyXdB=f‰iIBIJGX;DGHKJ|erXdỲaKTyiYJqTWP.PGTpº„iIHmPGT)Z[T)B„DGJ)kdlOFITc’iIBYhWDGHKN>B$cuNdPyHmDpkYlOFIT}LT)HKg>F„DxcuiYBIhWDGHKNdBSXdaKaKNpL'JyX‰J|n_J|DGT)Ẑ XdfYZ[HKBIHKJ|zDqPjX;DGNdPODGN‰fYT‘e=BITyX JqTWDxNQcƒTpXQJqHKaKn6h)iYJ|DGN>Z[HKtpXQÌaKT}FYN>J|DO^_PGNdeIa\TWJ)kIlOFYTDGHKZ[T)J‰JqFYNpLÈN>BYamnoFINpL"aKN>BIg x}0~c'€''x DGN„N>R€DGNEeIB=foXQBsN>^YDGHKZ$XQaÌXdJqHKhMH\fYT)X‰HKJDGF=X;DOeIPGJ|DDGFIT}iYJqTWPxPGTpº„iIHmPGT)Z[TWB DGJXQPGT0JGXQDGHKJ|e=Tpf{XdBIfh)N>B_e=gdiYPjXQDGHKNdB~k~@‡BoXdfIf_HKDGHKNdB€DGNDGFYH\JMDGHKZ[T>“ cr9†A‡HxA€ Jq^rT)B„D N>B†Xp¦ zDGFYT)B[XQJZ$XdB„nfYTWcuXdiYaKD^=XQh‘RdXdgdT)JX;PGT}XdfIf_TpfDGN3DGFITxh)NdBYe=gdiYPjX;DGH\NdBTWPjXdgdT_kK¼$JqT)h)NdB=f_J]^_PGT)^YPGN„hWT)JqJqHKBIgDGFYTUZ[N fYT)aœkƒlOFIHKJ3DGHKZ[THKJ BINdDJqFINpL'B$HKB$DGFYTxe=g>i_PGT0JqHKBYh)T0HKB6X3^YPjXQhWDGHKhpXdarh)NdBYeIg>iYPjX;DGHKN>B[DGN„N>a=DGFYH\JN>BIamnENdBIh)T cuNQP3TpXQh‘F‚•MT)ỲH\XdBE¦§TWPqz^YPGT)^_PGN„h)T)JqJqHKBIg6F=XQJ0DGN$`rT‰fYN>BYTXQJ0^rNdJqJqHKÌaKT>kvlOFIT3c’iIaKa1h)NdBYe=gdiYPjX;DGH\NdBEZ[N fYT)avcuNQP}DGFIT •MTWÌH\XdBSJ|n_J|zHKB„DGN[XQB n6TWV_HKJ|DGHKBIgUDGN„Nda1XdBIf{DGFIT}BITWV DyJ|DGT)^NQc©DGFIHKJxPGT)JqTpX;PGh‘FEHKJ'DGNJqHKN>B~k_lOFYT0T‘VYTWh)iYDGHKN>B[DGHKZ[T)J.g>TWDcœXdJ|DGT‘P'XdJ.DGFITyB_iYZ`rTWP.NQc~iYJqTWPPGT‘zDGTWZ HKJ.^_PGT)JqT)B„DGTpf HKB»m¼>½õkdlOFITxZ[N f_T)a F=XdJ©BYNdD`rT)TWBHKBIh)NQPG^rNdPjX;DGTpfiYZ`rTWPxNQc©JqiIHmDjXQÌaKT h)N>B_e=g>i_PjXQDGHKN>BYJ)kDGFITMBòó~ô èvÔ æ Îmä æ ÖCÐmØpÑÕCÍjÏCä§ÎÖCÏŽ97‘HKBIg[^YPGNQDGNdDCnY^rTdkhWN>BIJ|DqPGiYhWDyX‰LNdPGRû 0 h ›¬« h v h ª A#*Ÿ+©¨#ªi˺„iIHmPGT)Z[T)B„DGJ}HKBYhWPGTpXdJqT[`rTWhpXdiYJqT$X>fIf_HKBIgBYTWL h)NdBIJ|DqPjXdHKB„DGJMPGTpf_iIh)T)Jñ ÷ á – ð ÷ á – ð — 2 ñpñDGJ)kDGN‰DGF=XdBYRUDGFITMPGTWc’TWPGT)T)J'cuNQPyFIT)aK^Yc’iIavh)N>Z[Z[TWBh Î h ¢ h ªi+ h€#¢ñ ÷ á › š ÷ á ˜¡–2 áñp÷ š ÷ïpñ 2 á š ñ ÷ á÷ ˜2 áñp÷ ˜ ÷2ï 2 áï ˜ ÷ á22 áñp÷ ð ®2•¯ßÍ ê Ðæ ѱ°Oô§Ó³²Wé=ÐmÑQä>î_á5´.Ô æ ÐmÎæ)ê ÎmÍ æ Öµ¢ /6x‡,©Ÿ_/ û .&L£¡LONQPGR[N>B$N>^_DGHKZ$Xdarh)NdBYe=gdiYPjX;DGH\NdBIJOFIXdJ§`rT)T)BÆN>J|DxNQc~DGFYT0T‘VYHKJ|DGHKBIg¯R¹á'°ÍGÎÙ–Øpѧç æ Ñ>çº0á>é=ÐٖχۇܧÐÖ.»pá+ÚܧÍxÏ Ö æ)ê ÎmÍã3Ødç§ÍGÎ_χÍGã æ Ñ;Ö‡ÐmÛGÏ©Ù’ØpÕÎmØpÝpÐmÛ3à§Õ‡ØpÝpÕ ®÷ ã3ã3Ðmѧݧá óœÑ½¼‰¾ _¿BÀ.ÀBÁ¡Â+ÃAÄ¡ÅY^ÆÇœ+ÈÀVÉ¡œ+ÈËÊBÃ'œžÀ ¾ Ã9Ÿ>œ:Â:¡Ã9Ÿ¡æh)N>BYh)T)B„DqPjXQDGT)f‚HKBEDGFIT‰XQPGT)X6NQc ¯ µ ¸ © ® ¯ ¨‘µ ÂG° ° ª=¨ ² ª ­ k+@CB€XUPGT)JqNdiYPGh)TÓOåAýÞf´§ä§Ýpä§ÏCÖ 2 –¡š¡š>á„Úܧ͹óœÚsë~Õ‡ÍGχÏjá`=XQa–XQBIh)HKBYgU^YPGNdÌaKT)ZLT3XQPGTMgdHK¦§T)BSX]JqTWD'Ndcx¨j©Qª Ģ® ³$µ ¯j¸ DGF=X;DxTpXdhjFæ ѧÛGÐmѧ݉ÖCØ]ÛjØpÑdú„Ýpä§Õ‡Í0ã3Ødç>ä§Îæ ÕÏ ×>Ï Ö‡ÍGã3Ï‘á Ê^ÔCÔ5ÔÕÊ•Ã'œžÀ + ÂÖÄ>À_Ã'œ‰×HØ¡ÅBÙh)N>BYJqiIZ[T XUJq^rT)hWHKeIh3PGT)JqN>i_PGh)T>k+lOFYTWPGT]XQPGT]XdaKJqN$JqT)¦§TWPjXQaƒÃ ¯ ©p´ ® ¨‘µ ¯j¸Þ1ë æ ÖCÕ‡ÐmÒ†ådÐmã3ØpÑ§Ï‘Þ æ ѧçoÚÐmã3ØSådØpÐmѧÐmѧÍGÑIá”å;Ö æ)ê ÎmÍã3Ødç>ÍjÎ ÏCÍjã æ Ñ;ÖCÐmÛjÏ©Ø)Ù·©ÍGÐmÝpÜQÖÛGØpÑ§Ï Ö‡Õ æ ÐmÑQÖÕCä§ÎmÍGÏ‘áYóœÑV¼‰¾ _¿BÀ.ÀBÁ¡Â+ÃAÄ¡Åo.ÆæDGF=X;DMg>TWBITWPjX;DGT‰DGFIT PGT)JqNdiYPGh)T)J)k~lOFYTg>N>Xda©HKJ}DGN$e=BIfEX6JqTWD}Ndc^YPGNdz®ð ¯óœÎmÒdÒ æ ô§ÐmÍGã3ÍGΣݜ+ÈÀMÞ ÂÆBœ+ÈÐÊBÃ'œžÀ ¾ Ÿ¡œ£Â+>Ã9Ÿ¡ Ì >Ã_Æ•À ¾ ÀÃ9¿BÀo>ÃÎÍLBÄ¡Â:¿ ¼Z¾ .Ä ¾ Ÿ¡ÏÐÏÚÂ+ÃAÄΟ>Ã9ÁfYiYh)TWPGJ§DGFIXQDg>T)BYTWPjXQDGT)J§DGFITxPGT)JqN>i_PGh)T)JDGFIXQDh)N>BYJqiIZ[TWPGJ§iIJqT>k9¤.XdhjF^YPGN f_iIh)TWP}F=XQJMXdaKJqNX{f_H\J|DGHKBYhWD[¨G© Ģ± XdJqJqHKg>BYTpf‚DGN$HmD XQB=fSLOT LxXQB DDGN‚Z[H\BYHKZ[H\tWT$DGFYT[DGNdDjXdaxhWN>J|DUNQc}^_PGN fYiYh)TWPGJ‰DGFIXQDXQPGT6DjXdR§T)BsHKB„DGN¯ó|áYô§ÐmÍGã3ÍGÎ£Ý æ Þ ëváIådÐmã3ØpѧÏjÞ æ ѧç[ÚxáIåQ×>Õ–øÝ®ïDGFITMhWN>BYeIg>i_PjXQDGHKN>Bvkæ Ñ>ÍjÑYá0ådã3Ødç>ÍjÎmϵ9´ÏC×dÏCÖCÍGãÙ’ØpÕ æ ѧÏ^·1ÍjÕ}χÍqÖMà§ÕCØpÝpÕ æ ã3ã3ÐmѧݧáUóœÑá¼Z¾ _¿.ÀBÀBÁ¡Â+ÃAÄ¡ÅV^Æœ+ÈÀ±â¡œ+ÈËÊ•Ã'Ù_XdỲH\B]XQB=fHÒYPGT)iIfYTWP§» Q½„Z[N fYTWa\T)f3DGFYT§^_PGN>Ỳa\TWZ¤iYJqH\BYg0hWN>Z[^rN>JqHmDGT÷pñpñpñ á® ˜â1ܧՇÐmÏ Ö‡ØpÏ¥Ìyá$ë æ à æ ç§Ðmã3ÐÖCÕ‡ÐmØpäIá´ç§ç>ÐmχØpÑ>ö ¯ ÍGχÎmÍq׉ëƒä ê ÎmÐmχܧÐmѧÝMâ1Øpã3à æ ÑQ×;Þ>óœÑ§ÛpÞ 2–¡– ï áÑh)N>BYJ|DqPjXdHKB„DOJGX;DGH\J|cuXdhWDGHKNdB~kYlOFIT)HmP§`=XQJqH\hyH\fYTpX3HKJ§DGN XQh‘FYHKT)¦§TyN>^YDGHKZ$XQaKzHmD‡n ` n XdfIfYHKBYgAXoBITWL h)NdBIJ|DqPjXdHKB„D6DGNoDGFITEJ|n_J|DGT)Z TpXdhjF¥DGHKZ[T‚X¯ß æ ѧÐmÍGÎrå æ)ê ÐmÑ æ ѧç‰èƒä§ÝpÍGѧÍyâá>ò„Õ‡ÍGä§ç§ÍGÕ‘á~ìàdÖ‡Ðmã3ÐÖ» æ ÖCÐmØpщã3ÍqÖCܧØdç>Ï® BITWLÄJqNdaKiYDGHKN>BSHKJxcuNdiIBIfvk_@Cc~DGFIT0c’N>iYB=f{JqNdaKiYDGHKN>BSFIXdJ'XhWN>J|D{‰“_DGFITh)N>BYJ|DqPjXdHKB„DU¨G© Ģ± ¥ {ŠH\J0X>fYfYTpf$DGNUDGFIT3^_PGN>gdPjXQZSkrlOFYH\J'cuNQPGh)T)JyDGFITÙ’ØpÕ]ÛGØpѧÏCÖCÕ æ ÐmÑ;Ö‰Õ‡ÍGχØpä§ÕCÛGÍ[à§Õ‡Ø ê ÎmÍGã3Ïjá óœÑ Ì ¡Ã_ëÄ¡è ¾ Ÿ¡œ£Â:¡Ã ¼ Ÿ•ÜAÀ ¾ ÅiIBIfYTWPGamn_HKBIgMT)BYg>HKBIT'DGNMe=BIfN>BYamnU`rTWDqDGTWP§JqN>aKi_DGH\NdBIJ)k_lOFYT0XQ^I^_PGN§XdhjFÆ ¾ ¡Ïìœ+ÈÀÐíéíMíéÊËã± ¾.ä Å^ÈîÜfïÀ_Ã'œé×HØ¡ÅBœ£À_ÏÐÅÚÛìœ+ÈÀ_ ¾h)N>B_e=gdiYPjXQDGHKNdBIJ)k_lOFIT‘n[h)N>Z[^YiYDGTxDGFIT'PjXQDGHKN]NdcƒXdhWDGiIXda=PGT)JqNdiYPGh)T}fYTWz® –¯ÚÐmã3ØåQØpÐmѧÐmѧÍGÑ æ Ñ>ç{óœÎmÒQÒ æ ô§ÐmÍGã3ÍGΣÝFIT)i_PGHKJ|DGH\hWJyDGFIXQDyLON>iYa\fe=B=f{g>N„N fv“=ÌiYDyBYNdD0BIT)h)TWJqJGXQPGHKamnEN>^_DGH\Z$XQaœ“æ áyßÍqÔ;ÍjÎmØpà>ÐmÑ§Ý æ ç§ÍGÛjÎæ Õ æ Ö‡ÐÔ;ͼZ¾ ¿BÀBÀBÁ¡ÂWÃAÄ>ų^ÆJqJqHKÌaKT fYi_PGHKBIg DGFITMh)NdBYeIg>iYPjX;DGHKN>B^YPGN„h)TWJqJ)kñ ¯ÚxáYåQ×>Õ–øÝ æ Ñ>ÍjÑYáZ´¥Õ‡ä>ÎmÍGö ê„æ χÍGç‰Ù–ØpÕ‡ã æ ÎYã3Ødç>ÍjÎIØ)ÙƒÏCØ)Ù–Öž· æ ÕCÍ'ÛjØpÑdú„Ýpä>ö®22–¡–¡–>áN>i_P[fYT‘e=BIHmDGHKN>BANQc3XdBANd^YDGHKZ$XdaOhWN>BYeIg>i_PjXQDGHKN>Bvk.lOFIT0›H\JBINdDÕ æ ÖCÐmØpÑIá9ôÍGÏ‡Í æ Õ‡Û|ÜÇô.ÍGà ØpÕCÖ!´ ïpï Þ;̧ÍGÎmχÐmÑ>ÒdÐ>ӧѧÐÔ;ÍGÕ‡ÏCÐÖœ×yØ)Ù ÚrÍjۇܧѧØpÎöæ)ê ØpÕ æ Ö‡ØpÕ ×UÙ–ØpÕÚܧÍGØpÕ‡ÍqÖCÐmÛ æ Î~â1Øpã3à§ä>ÖCÍGÕ'ådÛGÐmÍGѧÛGÍpÞIÌ.ÍGÎmχÐmѧÒQÐuÞØpÝ)×;ÞYéѧçIÞ ß§ÍjÛGÍGã ê ÍGÕ 2–¡–¡–>á ò+ÐmѧÎæLOT)aKayJqiIHmDGTpfAcuNdP$PGT)JqNdiYPGh)TEÌXda\XdBYh)HKBIgo^_PGN>gQPjXdZ[J[Ìi_D[Hmc3HmD$HKJ6T‘V_z` ½ “IHmD0g>XdHKBIJyJqiYþUh)HKT)B„D0T‘V_zDGT)B=f_Tpf6L'HmDGFLT)HKg>F„D0h)N>BYJ|DqPjXdHKB„DyPGiYaKT)J‰»^YPGT)JqJqHK¦§T'^rNpLOT‘P§DGN XQa\aKNpLÄX}PGT)a\X;DGH\¦>T)amnUh)NdZ[^=Xdh‘D.PGTW^YPGT)JqT)B„DjX;DGH\NdB[NdcDGFITM^_PGN>Ỳa\TWZSkχØpÎÔdÐmѧݧá Ê^ÔCÔ5ÔøÔCêîÜAÀ ¾ œ Þ 2 ÷}÷ µð – —]ï ˜>Þ¹ æ ÕCÛ|Ü>öž´§à§Õ‡ÐmÎ 2–¡–>dá&

¡¢¢¢¢¢¢IPAS: An Integrated Application Toolsuite for theConfiguration of Diesel EnginesDr. Carlo BachAbstract. In the presentation the application toolsuite IPAS for configuringand offering diesel engines will be demonstrated.While IPAS provides a complete set of applications for the quotationand order taking process we will mainly focus on the configurationprocess as seen by the end user and the product modeldeveloper. The highlights of the configurator as parallel configurationsand reconstruction of old configurations will be explained. Anintegrated development environment to build up, test, and maintainproduct models is described as well.Experiences made during the project will be discussed.1 THE IPAS PROJECTMotoren- und Turbinen Union GmbH Friedrichshafen (MTU [3]) inGermany, together with its subsidiaries, forms the Diesel PropulsionSystems Division in the DaimlerChrysler Group and is one of theworldwide leading manufacturers of large diesel engines and completedrive systems. Diesel engines in the 35 to 7,400 kW powerrange are manufactured for marine propulsion, heavy vehicles, powergeneration and railroad applications.In order to handle the growing demand for customer specific configureddiesel engines MTU initiated a project called IPAS (IntegriertesProjekt Abwicklungs System) in 1996. IPAS provides a completesuite of applications to handle the quotation and order takingprocess. At its heart an interactive configurator masters the technicalcomplexity of the diesel engines.In late 1998 the applications went into productive use at the headquarter.Meanwhile several improvements especially in the managementof the configuration knowledge could be realized. Currently thesystem is going to be deployed at MTU’s subsidiaries world-wide.The tool suite is in daily use by about 70 users.1.1 The Application DomainMTU offers not only single diesel engines but complete propulsionsystems for various application domains. As illustrative example wewill concentrate in the following, however, on a marine application.A typical quotation for a shipping company handles a fleet of twoto four ships each consisting of several diesel engines and controllingequipment. E.g. a ship needs normally two engines for propulsion,one engine for power generation and computer systems for steering.All these engines have to be configured differently to cope with theindividual requirements.University of Applied Sciences Buchs, Departement of ComputerScience, Werdenbergstrasse 4, CH 9471 Buchs, Switzerland, email:carlo.bach@ntb.ch, www.ntb.chFor example the location of an engine in the hull - wether it is onthe left or the right side - decides on which side the oil dipstick hasto be mounted (right and left). Of course, an oil dipstick on the leftside of the engine is a different part than one on the right side and theengines itself - although very similar - are quite different in terms ofthe parts involved.The configuration results in a hierarchical parts list which can becalculated and printed as Microsoft Word documents.As this small example shows, the engines have a great varianceand are therefore quite complex. A single engine consists in a finalconfiguration of about 400 parts out of several thousand possibleparts.Besides of the technical complexity an offering process may takefrom some weeks to several months or even years. During this periodof time already configured engines have to be reconfigured becauseof new customer requirements or since the diesel engine type itselfhas changed technically. Therefore adaptation of old configurationsis an integral element of the tool suite.To handle this complexity MTU decided to develop a quotationsystem consisting of a configurator and all the applications needed tosmoothly deal with the quotation and ordering process.1.2 Application OverviewIPAS provides sales people at MTU with the following six highlyintegrated applications:PO: is the so called project folder (Projekt-Ordner). It offers ahierarchical view on projects, subprojects and all the documentsgenerated by the other applications. PO allows to access projectinformation at all subsidiaries and is responsible for the distributionof the relevant application data between different locations. Italso stores versions of quotations and orders.ADMIN: is used for the management of customer and project informationcommon to all applications.CONFIG: is the main application for the technical configurationof ships with several engines. It is used alike for quotes and fororders.CALC: calculates prices based on the detailed technical configurationgenerated with CONFIG and prints detailed price lists.TERMS: prepares a written offer based on text components. Variousparameters can be extracted from the technical (CONFIG) andthe commercial (CALC) configuration.NOTE: manages the order taking, the production, and the deliveryof the ordered engines at MTU itself.To work properly these end user applications need a lot ofbasic data which are maintained with several other applications.91

¢¢¢¢¢¢¢¢¢¢¢¢¢The central application for the management, test, and maintenanceof the configuration knowledge is PMADMIN (Produkt-Modell-Administrator).1.3 Application CONFIGWith CONFIG sales people can interactively configure diesel enginesfor a fleet of ships and manipulate them afterwards. The applicationsupports the following main features:The user has first to select an engine type which will determinethe prodcuct model. Each product model exists in several versionsdepending on how much it changed over time.CONFIG presents always a complete and technical correct solutionas far as the configuration knowledge is valid. Choices technicallyforbidden by the configuration knowledge can not be selected. Allselections are performed really interactively in typically less thanone second.The user can configure the engines based on a sales model and/oron an engineering model. The sales model lists about 30 to 60 easyto understand properties each of them with several alternatives. Inthe engineering model 2000 to 6000 parts describe the detailedassembly of an engine with all its variations.It is always possible to switch between these two views since theconfiguration engine propagates changes in both directions.The configuration engine supports the parallel configuration ofdiesel engines. By default all engines are configured together. Butthe user can deliberately select a subset of engines and can evenchange the set any time during the configuration process.An individual instance of the configuration engine is created foreach element in the set of selected engines. The user interacts witha so called leading engine in the set. All changes in the leading engineare duplicated whenever possible in the other configurationsin the set. Conflicts are reported to the user.This feature reduces the configuration time for large quotationsdramatically.The user can modify existing or insert new components in theproduct model on a per offer basis. The configuration engine integratesthem for the current user session into the product modelalthough it can not test if they are appropriate and technical compatiblewith the product model.Configurations can be reconfigured at any time, e.g. if a customercalls for modifications.The configuration engine can adapt configurations based on olderproduct models to new models. Conflicts are reported to the user.The configuration engine uses the following method for this reconstructionprocess: When a configuration is stored an identifierof the product model used and only the explicit choices made bythe user are written to the data store. All selections made by thesystem are left aside.If a configuration has to be restored with the same product modelas stored the configuration engine selects first the choices done bythe user last time. Afterwards all other selections are done automaticallyagain. In the case just described the reconstructed configurationis absolutely the same as the original one and no conflictscan arise since the same unmodified product model is used.The same mechanism is used for the reconstruction with a differentversion of the prodcut model (typically a more actual one). Inthis situation, however, several conflicts can occur.First, if a choice is not available in the new product model anymore this conflict situation is written to a log and the system willpostpone the decision upon which variant should be selected untilall other choices are reconstructed.A second conflict situation has to handle choices of parts whichare not available at the same place in the parts list hierarchy buthave moved. In this situation the system refines the configurationstepwise and tries to find the choice after each step again.Finally, the original configuration is compared to the reconstructedone. All differences are written to the log and presented to the user.This reconstruction mechanism works best if product modelschange only slowly over time. Since it is based on the namingof properties and components it is important to keep the namingconventions while the product models evolve.This feature is mainly used for long running quotations or orderswhere ships are delivered over a long period of time, e.g. one shipper year.1.4 Application PMADMINPMADMIN is an integrated development environement for the management,test, and maintenance of product models. It is used mainlyby the diesel engine engineers who have deep knowledge about theirproducts.Since the creation of product models is similar to the programmingof application programs PMADMIN provides a lot of featuresanalogous to those known to software engineers from visual developmentenvironements. The users of PMADMIN, however, are notvery familiar with software construction. Therefore the applicationprovides all tasks in a visual attractive fashion.The product model used by CONFIG is a result of a transformationinto the configuration engines own language and a compilationprocess.PMADMIN supports the following features:Creation and modification of product models: PMADMIN providesthree categories of components: properties, parts, and rules.Each category represents one aspect of configuration knowledgefor the diesel engine engineers, although internally these categoriesare not differentiated.Modularization: Product models are divided into so called libraries.Libraries can be reused.Versioning: PMADMIN keeps track if product models are used inactive configurations. These product models can not be changedany more since the reconstruction without conflicts could not beguaranteed.If changes are necessary PMADMIN creates a new version of theproduct model keeping as much parts unchanged as possible. Anew version has to be explicitly released for use.To get a fast overview PMADMIN can show differences betweenproduct models.Views: Several views on the configuration knowledge are possible.E.g. a user can look at different aspects of the product model likethe sales and the engineering model.Searching: PMADMIN provides extended browsing, searching,and crossreference capabilities. Since the product models growvery fast (up to 6000 components) good filtering and searchingtechniques are needed to keep an overview of the parts involved.Run-time debugging: With the run-time debugger the developpercan follow in detail the configuration process. Whereas in CONFIGrules are not shown to the user in PMADMIN this configurationknowledge is available.It is always possible to look at the current solution state and thedependency information.92

Since the product models are very large stepwise debugging isnormally to time consuming. Therefore, the debugger supports sophisticatedbreak points and watches statements.2 CONFIGURATION ENGINEIPAS uses a domain independent configuration engine [1], [2]. Theknowledge representation language applies techniques known fromconstraint, logic, and object-oriented programming. The language iscompletely declarative. As basic language constructs aggregation,generalization, and constraints similar to [4] are applied.The inference engine searches an AND/OR-lattice with a backtrackingmethod. To improve the search efficiency problem dependentheuristics can be employed additionally.In case of conflicts a dependency based backtracking algorithm iscalled, minimizing the changes in the current solution and keepingas much user choices as possible.3 EXPERIENCESThe applications in IPAS evolved over the project period and the configurationprocess was refined iteratively several times as end usersbut also product model developers gained experiences with configurationtasks.It has shown that powerful and flexible configuration engines areneeded to react in a timely manner to changed user requirements. Inour case it was used to adapt the configuration process as seen by theend user without the need to change the configuration engine itself.Another lesson learned is that the power of a configuration enginecan be overwhelming to the product model developers as wellas the end users. It is therefore absolutely necessary to provide productmodel developers with programming conventions to guide thedevelopment process.We introduced naming conventions which not only improved thecommunication between developers but also had a positive effect onthe reconstruction process in CONFIG. We also provided predefinedpatterns for typical configuration problems. Most important, theserules are supported by PMADMIN either in form of visual entrymasks or as check routines.Nevertheless the full power of the configuration engine can alwaysbe exploited if the need arises.The configuration engine was not designed exclusively for theIPAS system but is used in other applications as well, e.g. it alsoconfigures switching equipement in a batch process at the mobilenetworks division of a big Telecom company.ACKNOWLEDGEMENTSI would like to thank Michael Feldmann and the computerscience departement from MTU Motoren- und Turbinen-Union,Friedrichshafen.REFERENCES[1] ISE Software AG. Configuration Master User’s Manual.[2] C. Bach, An Interactive Knowledge-Based Shell for Configuration Tasks,Hartung-Gorre Verlag, D-Konstanz, 1994. also published as Ph.D. thesis,ETH Zuerich.[3] MTU Friedrichshafen. www.mtu-friedrichshafen.com.[4] H. Meyer auf’m Hofe, ‘Construct: Combining concept languages witha model of configuration processes’, in Papers from the AAAI Workshopon Configuration, (1999).4 IMPLEMENTATIONThe whole IPAS system is realized as a multi-user distributed clientserversystem. It runs under Microsoft Windows 95, 98 and NT. Thefront-end applications are written in Visual Basic and access datastored on a Microsoft SQL-Server 7.0 relational database. For printingan integration to Microsoft Word was implemented. The configurationengine is written in C++ and is available on Windows andUnix plattforms.5 CONCLUSIONThe IPAS system consists of a complete application toolsuite for thefast and reliable management of quotations and orders in a technicalcomplicated domain. At its heart stands a powerful domain independentconfiguration engine.As in the software development process programming conventionsare necessary to master the complexity of the configuration task.The IPAS system is in daily use at MTU for almost two years now.93

¢¥¦§Oliver Hollmann, Thomas Wagner and Andreas Guenter ¡EngConA Flexible Domain-Independent Configuration EngineAbstract. The knowledge-based configuration engine EngCon ispresented which is developed in a cooperation of TZI Bremen andLENZE GmbH & Co KG Hameln, Germany.We discuss the system architecture and the configuration techniquesused in EngCon. In our demonstration we try to focus on the differencesto the LISP prototype KONWERK which was developed at theUniversity of Hamburg, Germany.1 INTRODUCTIONThe configuration of products with a wealth of variants has enormouslygained in relevance over the last years. Customers increasinglyexpect consideration of their individual requirements on a product.There was a paradigm switch from mass production to mass customization.Intelligent configuration and design tools support salesmanagers, engineers, and customers to layout and configure individual,innovative, and complex products.The implementation of a knowledge-based configuration engine in acompany leads to more transparency and efficiency in the usage ofexpert knowledge. The specific configuration knowledge of a domainexpert can be used by colleagues or customers directly.In the automobile industry, for example, a customer can configure acar directly on the internet page of a company 3 4 and can order itwithout any personal contact to a dealer. An overview of online configuratorsis given in [Boehm et al., 1999].In this paper we discuss the domain-independent, knowledge-basedconfigurator EngCon. The main idea of the tool is methodically basedon the LISP prototype KONWERK (see [Guenter, 1995]). But in detailthere are some differences and extensions.The next section provides a short introduction to knowledge-basedconfiguration. Section 3 shows the configuration engine EngCon. Wediscuss the knowledge representation, problem-solving methods, architectureand system integration with CRM- and ERP-systems. Finally,a short summary and some future directions of EngCon aregiven in section 4.representation and algorithms generating a solution. There areseveral problem-solving methods for configuration problems (e.g.logic-based, structure-oriented, ressource-oriented, associative andfunction-oriented) which were discussed in [Brinkop, 1999] and[Guenter, 1995].The domain-independent configuration tool EngCon[Arlt et al., 1999] works with the structure-oriented configurationmethod. The tool is successfully used for the complex productconfiguration of electronic drives. EngCon is implemented in Javaand has an ontology for representing domain knowledge. Domainconcepts can be defined with parameters and relations in a concepthierarchy. Modeling descriptions for taxonomic (is-a), partonomic(has-part) and user-defined relations can be used. The action ofthe configuration engine can be controlled with declarative controlknowledge. Requirements and restrictions between configurationobjects are represented with constraints.3 ENGCON TECHNOLOGIESThe domain-independent, knowledge-based configurator EngCon issuccessfully used for the configuration of electronic drive systems.The structure-oriented configuration method is well suitable for technicaldomains with a wealth of variants and relations between thecomponents. The user can develop step by step the solution guidedby the configurator (see figure 1). In this section we discuss the technologiesof EngCon in detail.2 KNOWLEDGE-BASED CONFIGURATIONSolving a configuration task means selecting, parametering, andcomposing a system from single components to a valid solutionaccording to all requirements and constraints [Sabin, 1998][Guenter, 1995]. A configuration task consists of a problemTZI, Center for Computing Technologies, University of Bremen, D-28359Bremen, Germany, £ oho,twagner¤ email: @tzi.deHITeC e.V., University of Hamburg, D-22527 Hamburg, Germany, email:guenter@informatik.uni-hamburg.dehttp://www.opel.de/webkaufhttp://www.bmw.de/carconfiguratorFigure 1.EngCon System94

¨3.1 Knowledge RepresentationThe domain knowledge is represented in an object-oriented concepthierarchy.Domain objects are defined with parameters and relations.EngCon provides the taxonomic (is-a) and partonomic relation (haspart).(def-do:name :super-concept [:parameters ([]*)][:relations ([]*)])A facette might be for example a default value or a measurementunit. The representation of concepts is equal to the frame-based representationin KONWERK (see [Guenter, 1995]).The configuration process in EngCon can be structured in differentphases which are described by control knowledge (see[Guenter, 1992]). In a strategy we can focus the agenda generationon specific configuration objects. The processing of the agenda canbe controlled with agenda selection criteria. You can define a stack ofcalculation methods (see subsection 3.2) for the evaluation of a configurationstep. Strategies are changed if the current agenda is emptyor the start condition of a strategy with a higher priority is true.The control knowledge of EngCon describes the funcionality ofan intelligent assistant. A user can configure either interactively orguided by the tool.Other than in KONWERK, the look and feel of configuration objectsin a user interface can be defined with declarative presentation concepts:(def-presentation:name :super-presentation :concept | [:strategy ][:parameters (*)][:relations (*)])relations provided in EngCon (tuple, function, java, specialize, decompose)which are defined in a conceptual way. The bindings ofconstraint pins are defined with variable-pattern-pairs. The constraintrelations are instantiated incrementally during the configuration process.Only the constraints for actual configuration objects are in thescope of the constraint propagation.(def-conceptual-constraint:name :variable-pattern-pairs (()*):constraint-calls (()*))Tuple constraints can be defined directly in a relational database system.The evaluation is done by SQL-queries via JDBC.It is possible to specialize or decompose configuration objects automaticallyvia constraints.JAVA constraints are a flexible and powerful way to define customizedconstraint relations. The functionality of a constraint canbe implemented in a JAVA method with an clear API to the EngConconstraint-solver. With this powerful mechanism the availability of acomponent for example can be checked through a request to an ERPsystem.If the values of a configuration object are restricted in a way thatthere is only one possible specialization in the concept hierarchy,the specialization step will be automatically done by the taxonomicinferencemechanism of EngCon. Complex configuration objectswill be decomposed automatically to the minimum number of componentsdefined in the knowledge base.3.3 IntegrationThe concept hierarchy of EngCon corresponds to a company’s productmodel. In the knowledge acquisition process the concept definitionsfor the bottom levels of the concept hierarchy can be generatedautomatically from the database of an ERP-system (see figure 2).The higher levels of the concept hierarchy have to be modeled by adomain expert and knowledge engineer.EngCon im UnternehmenA parameter of a presentation concept might be for example an iconof a component which should be presented for a configuration objectin a specific situation of the configuration process. Depending onan interacting user, it is possible to describe different configurationmodes (e.g. novice and expert) and present detailed informations.CAS / CRMOfferingOrderERP SystemSalesDistributionMarketing Logistics Finance3.2 Problem-Solving MethodsThe configurator EngCon works agenda-based and provides severalcalculation methods to determine the value in a configuration step. Ina top-down design a configuration object can be parametrized, specializedand decomposed into parts. In a bottom-up or mixed design,components can be integrated in complex configuration objects, too.A configuration decision can be made by:EngConConfigurationEngineEngConKnowledgebaseOrder Delivery InvoiceCustomers Materialsuser-interaction©default-value-takeover©EngConProductModelConvertingModelingERPProductModel(C) OHO 06/99dynamic-default-calculation (e.g. min/max value)©calculation functions©Figure 2.EngCon ERP-Integrationconstraints©taxonomic inferences©Constraints are used to check the consistency of a partial solutionand to restrict and propagate values. There are different constraintThe solution of the configurator can be directly integrated in a supplyor an order. EngCon provides interfaces to CRM-systems. Theconfiguration process can be initialized by a CRM-system and the95

output can be exported and included in the supply text or order text.A closer integration with an ERP-system of a company can beachieved by the implementation of JAVA constraints which initiatespecific transactions (see subsection 3.2).3.4 ImplementationThe configurator EngCon has a flexible component architecturebased on JAVA-2 technology. The platform-independent JAVA technologyallows the usage of the configurator in heterogeneous softwareenvironments and provides a good basis for internet configuration.The interface of EngCon can be bridged for example withJAVA-RMI, and the user interface might be an Applet.The kernel of EngCon can be integrated in domain-specific user interfaces.It is possible to embed the configurator via middleware technologyin non-JAVA environments.In an early phase of our project we integrated the configurator viaSUN Microsystems ActiveXBridge in a Visual Basic user interface.[Hollmann et al., 2000] O. Hollmann, K.C. Ranze, H.J. Mueller and O. Herzog.Conflict Resolution in Distributed Assessment Situations, inH.J. Mueller and R. Dieng (eds.), Computational Conflicts - ConflictModeling for Distributed Intelligent Systems, Springer-Verlag, 2000.[Sabin, 1998] D. Sabin, R. Weigel. Product Configuration Frameworks - ASurvey, in IEEE Intelligent Systems July/August 1998, Seite 42-49.4 SUMMARY AND FUTURE DIRECTIONSThe configurator EngCon is successfully used in technical domains.A future extension might support 3-D configurations with spatialconstraints.Another task for the future will be the storage of solutions and theircase-based retrieval. Time-intensive configuration processes can besaved, if the tool provides traditional solutions to a configuration taskwhich can be reconfigured.We are actually working on an online solution for the internet. Thereforethe knowledge representation should be transformed to XMLwhich seems to be the standard representation in eCommerce. Thereare several XML-approaches to represent product data in electroniccatalogues 5 or to define interchange formats 6 which can be integratedin EngCon.One more extension is the development of alternative (partial) solutionsand their assessment for decision support during a configuration.This will be interesting for online configuration, too, becausethere is no expert available to influence the customer in his decision.Configurations have to fit different heterogeneous requirementswhich can lead to various conflict assessments. There is a conflictresolution framework described in [Hollmann et al., 2000] which canbe integrated in EngCon for multicriteria evaluation support.REFERENCES[Arlt et al., 1999] V. Arlt, A. Guenter, O. Hollmann, L. Hotz, T. Wagner. Engineering& Configuration - a knowledge-based software tool for complexconfiguration tasks, in AAAI-99 Proceedings, Orlando, AAAI-Press 1999.[Brinkop, 1999] A. Brinkop. Variantenkonstruktion durch Auswertung derAbhaengigkeiten zwischen den Konstruktionsbauteilen, Infix, 1999.[Boehm et al., 1999] A. Boehm, H.J. Mueller, J. Rahmer, S. Uellner. A Discussionof Internet Configuration Systems, in AAAI-99 Proceedings,Orlando, AAAI-Press 1999.[Guenter, 1992] A. Guenter. Flexible Kontrolle in Expertensystemen zur Planungund Konfigurierung in technischen Dom”anen, Infix, 1992.[Guenter, 1995] A. Guenter. Wissensbasiertes Konfigurieren: Ergebnisse ausdem Projekt PROKON, Infix, 1995.[Guenter and Kuehn, 1999] A. Guenter and C. Kuehn. Knowledge-BasedConfiguration - Survey and Future Directions, in XPS-99 Proceedings,Lecture Notes in Artificial Intelligence No. 1570, Springer-Verlag,Wuerzburg, 1999.http://www.bme.de/bmecathttp://www.xmledi.org96