CONFIGURATION
`
`T"
`
`
`
`(cid:3) (cid:55)(cid:75)(cid:76)(cid:86)(cid:3)(cid:80)(cid:68)(cid:87)(cid:72)(cid:85)(cid:76)(cid:68)(cid:79)(cid:3)(cid:80)(cid:68)(cid:92)(cid:3)(cid:69)(cid:72)(cid:3)(cid:83)(cid:85)(cid:82)(cid:87)(cid:72)(cid:70)(cid:87)(cid:72)(cid:71)(cid:3)(cid:69)(cid:92)(cid:3)(cid:38)(cid:82)(cid:83)(cid:92)(cid:85)(cid:76)(cid:74)(cid:75)(cid:87)(cid:3)(cid:79)(cid:68)(cid:90)(cid:3)(cid:11)(cid:55)(cid:76)(cid:87)(cid:79)(cid:72)(cid:3)(cid:20)(cid:26)(cid:3)(cid:56)(cid:17)(cid:54)(cid:17)(cid:3)(cid:38)(cid:82)(cid:71)(cid:72)(cid:12)(cid:3)
`This material may be protected by Copyright law (Title 17 US. Code)
`
`A Configuration Tool to
`Increase Product
`Competitiveness
`
`Bei Yu and Hans Jurgen Skovgaard, Bonn Front Office Systems
`
`
`
`MANY COMPANIES NOWADAYS
`must rapidly develop and deliver products
`and product variants in a short time to meet
`increased customer demands and stiffer prod-
`uct competition. Product configuration (de-
`terminin g a set of components and their rela-
`tionships, and composing them into a product
`that satisfies customer requirements and
`design constraints) therefore faces the prob-
`lem of quickly providing these variants with-
`out incurring high costs.
`However, modern products have become
`increasingly complicated, incorporating many
`different technologies. Incorrect configura-
`tion solutions will inevitably require correc-
`tions and lead to high costs. So, product con-
`figuration also faces the challenge of de-
`livering a solution that is right the first time.
`Current configuration tools have not met
`these challenges, for three main reasons:
`
`
`
`ensure configuration correctness—that is,
`100% accuracy on the valid configuration
`solutions;
`a They can’t handle product complexity
`well enough. Complicated product struc—
`0 develop an effective approach for han—
`tures with numerous relationships lead to
`dling configuration consistency;
`0 handle configuration constraints;
`the hard configuration problems. No real
`solutions exist yet for these problems——
`I overcome the limitations of product-
`that is, no approach to product configu-
`lcnowledge maintainability; and
`ration can significantly decrease product
`support the whole development of a con-
`complexity.
`figuration application—that is, product
`salesPLUS is based on the concept of mass
`0 They can’t support configuration mainte-
`modeling and configuration—without
`nance well enough. Although several the-
`requiring programming skill.
`customization—that is, product configuration
`
`lO94-7167/98/$10.00 © 1998 IEEE
`34
`
`THE SALESPL US PRODUCT- CONFIGURATION TOOL
`
`
`
`EFFECTIVELY SOLVES COMPLEX CONFIGURATION PROBLEMS, a
`REDUCING COSTS WHILE MEETING CUSTOMER EXPECTATIONS
`
`
`IN REAL- WORLD APPLICATIONS.
`
`e.
`
`oretical approaches are available, they are
`impractical, because of the limitations of
`time, computer speed, memory, and so on.
`I They can’t maintain product knowledge
`well enough. Some maintenance tech—
`niques in existing configuration tools are
`also expensive and time-consuming.
`
`The salesPLUS1 tool can handle the com—
`
`plexities of product configuration, with highly
`efficient inference-engine peiformance and
`application maintainability. This commercial
`AI-based system effectively and intuitively
`models and configures products. It effectively
`produces and maintains consistent, accurate
`configurations that meet customer demands
`while significantly reducing costs.
`
`The sulesPlllS system
`
`
`
`
`
`generates customized solutions based on a
`stande product or product model.2 It adopts
`the computer-support-assistant philosophy:
`it is an assistant interacting with the user.3 The
`goal of using an AI—based approach was not
`superior performance, because the algorith-
`mic system staits out from a precompiled rep—
`resentation and is, as expected, several times
`faster, but maintenance savings.4 The main
`objectives of salesPLUS are to
`
`0
`
`0
`
`IEEEINTELLIGENT mung)
`
`CONFIGIT 1006
`
`CONFIGIT 1006
`
`1
`
`

`

`
`
`Product Information
`
`Final product to be sold
`
`,K
`\H
`Conli—g_uiation
`
`Modeling Product model--
`
`
`Figure l. The configurulion-design process.
`
`Types of objects. As part of the selection
`process during configuration, an object might
`involve an option that is yes or no, is a fixed
`number, or is an interval. Or, it might have a
`list of options where none, one, at least one,
`or several of the options must be picked.
`Accordingly, objects fall into these types:
`
`or several elements at a time. They are
`typically used when you have a set of
`options that can be selected individually.
`AnyOf objects are usually used in rather
`compact presentations or for a logical
`grouping of items in the product model.
`0 Time objects resemble Single objects.
`The only difference is that
`they are
`FALSE until a specified activation time,
`after which time they obtain the value
`TRUE. You can use Time objects, for
`example, to compensate for the asyn-
`chronous aspect of product events and
`product model releases.
`Info objects support textual informa-
`tion. The text passes information on the
`product or some components to the user.
`
`0
`
`Constraints. In salesPLUS, the relationships
`between objects in the product model, as well
`as design requirements, are constraints. The
`constraints deal with only the contents of the
`product model problem, not the computa—
`tional aspects. Thus, they deal only with stat—
`ing the problem, not programming the solu-
`tion. There are three kinds of constraints:
`
`0 Single objects have no fixed relations
`or multiple instances. These objects have
`a selection option of yes or no.
`- Enum objects can be enumerated and
`stated in a range—for example, [0.32].
`0 Interval objects let you can divide a
`numeric range into a rillmber of consec-
`utive nonoverlapping subintervals. With
`these objects, you can reason about the
`interval, not the exact value.
`0 Oneof objects have mutually exclusive
`elements. They are used to group a set of
`components from which one must be
`selected.
`.
`0 AtMostOne objects let you select one
`element at most. Otherwise, they are sim-
`ilar to OneOf objects.
`0 AnyOf objects let you select no elements
`
`
`
`
`
`
`
`
`For the whole life cycle of product de—
`velopment, configuration consists of two
`aspects: configuration design and configu~
`ration maintenance.5 Configuration design
`deals with creating configuration solutions;
`it involves selecting elements and the ways of
`configuring them. Configuration mainte-
`nance deals with maintaining a consistent
`configuration under change; this involves the
`consistency among the selected elements and
`decisions. When a decision for selected ele-
`
`ments changes, configuration maintenance
`must trace all the decisions that are related
`
`to the changed decision and revise them, if
`necessary, to maintain consistency among the
`elements and decisions.
`
`salesPLUS divides configuration design
`into two stages: product modeling and con-
`figuration (see Figure l). The product-
`modeling stage defines the product model
`and the classification (assortment) of prod—
`ucts and parts by means of the objects, prop—
`erties, allowable property domain, and con—
`straints. The configuration stage creates a
`specific product instance or variant based on
`that model. This configuration solution can
`be represented as a product specification, a
`sales order, or a parts list or bill of materials.
`salesPLUS incorporates configuration
`maintenance into the product-modeling and
`configuration stages. For configuration main—
`tenance, the systems uses a constraint—based
`approach that involves fewer, more intuitive
`constraints. It performs problem—solving to
`ensure that configuration is consistent and
`correct.
`
`Figure 2 gives a scenario for product con-
`figuration in salesPLUS. First, based on
`product
`information, salesPLUS creates
`product models. Then, through computer
`compilation, the system prepares the prod-
`uct models for configuration. Next, sales-
`PLUS helps the end user, who might be a
`designer, a sales engineer, or even a cus—
`tomer, make decisions on configuration
`details. Finally, it generates the configuration
`solutions.
`
`Product modeling. A product model incor-
`porates all the information that represents
`products or services. This information is
`encapsulated in objects, which involve re-
`sources and constraints. A model can consist
`
`
`
`,
`
`User
`
`selections
`
`End-user
`application—PC
`
`
`
`of several submodels; for example, a train
`Cousists of several cars. Objects might vary
`End-user application—Customized
`from physical parts (such as a screw), to sub—
`
`assemblies (for example, a speaker), to whole
`products (perhaps a car radio system).
`Figure 2. A configurulion scenario in salesPLUS.
`
`35
` JUlY/AUGUST 1998
`
`2
`
`

`

`
`
`logic constraints, arithmetic constraints, and
`warning constraints.
`Logic constraints control the combination
`of objects, thus stating which selections are
`legal and which are illegal. The operators
`allowed are the classical ones from proposi—
`tional logic, with the traditional operator
`hierarchy: NOT, AND, OR I XOR, and —)
`(implication) [ <—) (bi-implication). The con—
`stants TRUE and FALSE can also be used.
`
`The system also allows many special opera—
`tors having a comma—separated list of vari—
`ables as arguments. Such operators are short—
`hand for complicated logic expressions:
`
`0 Allequal (The elements must be either
`all TRUE or all FALSE.)
`0 Oneof (There must be exactly one TRUE
`element.)
`0 AtMostOne (There must at most be one
`TRUE element.)
`0 AtLeastOne (There must at least be
`one TRUE element.)
`Impossible (The elements cannot all
`be TRUE.)
`
`0
`
`set physical
`constraints
`Arithmetic
`(numerical) limits—for example, for deter—
`mining the power supply or the length of a
`train car. The operators allowed are the clas-
`sical ones from mathematics, + (addition), —
`(subtraction), and * (multiplication); and one
`of these comparison operators: == (equal
`[compare]), >= (greater than or equal to), <=
`(less than or equal to), > (greater than), or <
`(less than).
`Warning constraints can be violated with-
`out being fatal to the product configuration.
`Their violation means that you are in a very
`special situation and must be careful. For
`example, a computer has no network con-
`nection but still works. However, in most
`cases, the computer must be able to commu—
`nicate with other computer systems.
`
`Resources. An object may have a number
`of references, as basic data, to other data
`relations, business rules, and graphical user
`interface elements. These references are
`resources.
`
`be used as references for complex pricing
`structures or additional information.
`
`Product modulization. This methodology has
`recently become a hot topic in research and
`practice. As a configuration-support tool,
`salesPLUS supports modulization of prod—
`ucts into models and submodels. Engineers
`can work separately on the submodels. These
`submodels can then be linked into a whole
`
`product model. This is important for an inte—
`grated development environment; moduliz-
`ing a large product into manageable modules
`can reduce product complexity.
`
`The configuration process. During config-
`uration, salesPLUS makes a series of selec—
`tions based on the customer and design
`requirements, and maintains consistency
`between the selected elements and decisions.
`
`Some significant features of this process are
`
`Order-free selection. Unlike a decision—tree—
`based configuration, configuration decision
`making in salesPLUS is order-free. In other
`words, the user can start from any selection,
`in any order. This feature gives the user a lot
`of freedom to carry out configuration, com-
`pared to decision—tree or specific selection—
`dependency rules.
`
`Limits. Resources can be given upper and
`lower limits during configuration. This fea-
`ture lets the end user focus on needs (behav-
`iors and performance), rather than on select-
`ing objects.
`
`Optimization. salesPLUS has built—in opti-
`mization facilities. Both minimization and
`maximization are possible. The combination
`of limits and optimization makes salesPLUS
`very powerful. For car configuration, for
`example, the end user can state that at least
`200 horsepower is needed and then ask sales-
`PLUS to minimize the price.
`
`Default values. The user can set up a default
`value for his or her own reasons. During con-
`figuration, the user sets up these default values
`and salesPLUS inferences other values, based
`on the constraints. If the user decides that the
`
`default values will depend on other selections
`made later during configuration, he or she can
`define a set of conditional default objects that
`can be governed through constraints.
`
`
`
`
`
`inevitable. In salesPLUS, a user can change
`his or her decisions without worrying about
`the configuration’s consistency.
`
`System architecture. salesPLUS consists of
`four primary modules (see Figure 3).
`The Definer generates a product model
`that declares the relationships between ele-
`ments and constraints. With the Definer,
`modeling engineers model a product by
`means of a set of objects with constraints. It
`has facilities for checking the model’s con-
`sistency, for simulating and running the end-
`user application, and for creating the inter-
`face for carrying out configuration.
`The Customizer carries out configuration
`based on the product model. This process is
`interactive, to satisfy specific customer needs
`and requirements.~The result of the user’s
`selections and the system’s subsequent con—
`clusions is a specific configuration solution.
`Solutions can be printed, saved, or exported
`to other product-development tools.
`The Kernel holds an internal representa-
`tion of the product models and contains the
`heart of the system: the inference engine,
`which ensures configuration consistency and
`correctness. We’ll discuss the engine in more
`detail in the next section.
`
`The salesPLUS API (application pro—
`gramming interface) links application—inter-
`face modules such as the Definer and Cus-
`
`tomizer with the Kernel. Also, by accessing
`a number of kernel functions through the
`API, users can easily add new user-interface
`features to the Customizer or even develop
`new user interfaces.
`
`The user—friendly interface at the configu-
`ration stage is a purely data—driven interface
`based on product models. That is, when prod-
`uct models change, salesPLUS automatically
`creates an updated user interface based on
`the changed models. In addition, salesPLUS
`can support configuration over the Internet,
`using the same model created through the
`Definer.
`
`A product-configuration too] should be
`able to build a feature—rich product, should
`be based on an open architecture, and should
`easily integrate with other enterplise appli—
`cations. We’ve achieved this in salesPLUS
`
`
`
`
`
`Some objects are measured by quantity,
`through product modulization and the incor—
`which can be assessed. Typical resources for
`such objects are product price, manufactur—
`poration of well—defined integration points.
`This minimizes the effort required to imple—
`ing cost, power, space, and delivery time.
`ment the product in almost any environment.
`Resources are typically referenced in exter-
`nal tables, fixed or online, because they
`For example, We’ve developed an add-in
`change often—for example, price lists,
`interface to support customers’ special
`Freedom to make changes. In configuration,
`needs.
`which vary per country. Database links can
`changes of previous choices are typical and
`
`IEEE INTELLIGENT SYSTEMS
`36
`
`3
`
`

`

`
`
`
`
`
`Figure 3. The salesPLUS system architecture.
`
`inference engine needs to deduce the con-
`clusions, because the configuration solution
`space shrinks during configuration.
`
`Dynamic consistency maintenance. If the user
`tries to change a selection, and this change will
`negatively affect the configuration’s consis-
`tency, the system gives a warning. If the user
`continues with the change, the system pro-
`vides a list of selections that have been made
`
`that relate to the selection to be changed. This
`list informs the user that these selections will
`be affected and must be reselected to meet the
`
`change requirements. The user can decide
`which altematives from the selection list must
`be reselected. Once the user decides to redo
`
`selections, the system eases the relevant bound
`variables in the constraints.
`
`Boolean constraint handling. The inference
`engine’s power comes from the unique
`Boolean constraint-handling mechanism—
`that is, binary array-based logic mathemat-
`ics.8 This mechanism has been successfully
`applied to propositional logic in a finite
`domain.
`
`During compilation, salesPLUS compiles
`the product model with constraints to create
`several truth tables. In array—based logic, any
`propositional form is transformed into a truth
`table in binary-array form. The mathematical
`properties of
`logical arrays
`allow the
`execution of any logical inference through just
`three primitive array operations: outer prod-
`uct, generalized transposition, and reduction.
`These operations can be implemented effec-
`tively by using the com—puter instructions
`AND, OR, and XOR on 32 bit-words, thereby
`achieving parallel processing.
`In addition, the compiler preprocesses the
`product model such that it contains truth
`tables in compressed—array form, including
`attached information such as resources. Dur—
`
`
`
`ing runtime the configuration process takes
`advantage of the already compiled informa-
`plexity. This kind of problem leads to a large
`or two seconds; this limit is independent of
`search space for solutions. Although some
`tion. Referencing the truth table at runtime
`the platform. In our experience, the more
`lets the configuration engine deduce all the
`algorithms such as forward-checking perform
`selections the user makes, the less time the
`consequences faster than would an engine
`better
`than traditional backtracking ap-
`
`37
`.llllY/AUGUST 1998
`
`inference engine design. The inference
`engine’s objective is to handle constraints
`such that c01rect configuration solutions can
`be derived as quickly as possible. It is an
`effective constraint-based problem solver
`with our patented technology6 that enables
`the entire system to carry out complicated
`product configuration in an effective time.
`During configuration, avoiding situations
`where selections contradict each other is very
`important. Some configuration systems have
`addressed this inconsistency issue, using dif—
`ferent approaches. Our inference engine
`uniquely ensures such consistency early in
`the decision-making stage—that is, it can
`reason with incomplete information within
`a guaranteed response time.
`For example, assume that there are two
`constraints, “A —) B or C” and “B or C —) D.”
`If we know that A is true, we can directly
`deduce D to be true without knowing the val-
`ues of B and C. In many configuration sys—
`tems, however, D cannot be inferred directly
`through the two separated constraints. This
`situation might cause inconsistency because
`it lets the user assign D. If, for example, we
`assign D to be false, the next evaluation of B
`or C will cause a conflict.
`
`Many systems handle this problem by
`informing the user that a contradiction exists
`and displaying the conflicted constraints. The
`user must handle the problem, either by using
`backtracking or by adding another constraint,
`“A —) D,” to avoid the conflict. Nevertheless,
`applying backtracking will result in time—
`consuming configuration, and adding a new
`constraint will lead to redundant constraints
`
`that are not directly linked to the product,
`thus complicating maintenance.
`The salesPLUS inference engine, in con-
`trast, can avoid poor performance and redun-
`dam-constraints maintenance while ensuring
`proper configuration. To provide configura-
`tion consistency and correctness, it employs
`complete deduction, graceful degradation,
`dynamic consistency maintenance, and
`Boolean constraint handling.
`
`Complete deduction. A configuration prob-
`lem is NP-hard; that is, it grows exponentially
`in time with the complexity of the product to
`be configured. The number of product ele-
`ments, the various constraints, and the prod-
`uot model’s level of detail cause this com-
`
`
`
`proaches, time efficiency is still a problem.7
`Complete deduction uses constraint-satis-
`faction—problem technology with time effi-
`ciency. This approach starts with a set of vari-
`ables with domains and a set of constraints
`
`among these variables. Then, when the user
`makes a configuration decision, it determines
`the current valid configuration solution space
`without violating the given constraints.
`Complete deduction consists of a series of
`algorithms with increasing time complexity.
`These algorithms work together to carry out
`three basic sequential steps:
`
`(1) Propagation—making all the relevant
`constraints and examining their conse—
`quences, based on the configuration.
`(2) Determination of solvability—evaluat—
`ing each undetermined selection option
`to see whether a corresponding config-
`uration solution exists.
`
`(3) Completion—guaranteeing that all
`possible consequences have been
`determined.
`
`This approach, in a sense, maintains con-
`figuration consistency by ensuring a valid
`configuration solution space in the runtime
`environment. In other words, selections are
`bound, in a shrinking configuration solution
`space, toward solutions while configuration
`progresses. This approach guarantees the cor-
`rectness of solutions by pruning inconsistent
`selection choices from the selection space.
`The number of the basic steps that com-
`plete deduction carries out depends on three
`factors: the specified maximum allowed time
`(see the next section), the product's com—
`plexity, and the computer’s speed.
`
`Graceful degradation. When a problem is
`NP—hard, the inference engine might take
`longer than desired to establish all the con-
`sequences. So, to assist the user, the engine
`employs graceful degradation:
`it tries to
`deduce as much as possible in a time frame
`given by the user. This method gives the user
`more control over configuration.
`To specify the time frame, the user specifies
`the MaxTime time—limit parameter when
`invoking the engine. The engine will then give
`control to the user when that time limit expires.
`It can then run as a background process until
`the user interacts with the system.
`A suitable time limit should be around one
`
`
`
`
`
`=0
`
`4
`
`

`

`
`
`
`It is impossible to have both air-conditioning and automatic air-conditioning.
`The Turbo Cabriolet comes with the Turbo engine, metallic paint, leather trim, and
`cruise control.
`An ordinary Cabriolet comes with the 2.1-liter engine.
`Ordinary Cabriolets cannot have the trim color marine.
`Models with red, grey, or green paints cannot be ordered with marine trim.
`Models with beige or green paints cannot be ordered with puma trim.
`Cars with the Turbo engine must be ordered with ABS brakes.
`A sunroof cannot be ordered for Cabriolets.
`The delivery times are 14 days for the Saab 900, 21 days for the Cabriolet, and 35
`days for the Turbo Cabriolet.
`Either air bag, or ABS brakes, or both should be selected.
`
`
`
`TFFE’TmPS-T’P???
`
`J:
`(a)
`
`NEW: Leather_Trimée Trims[Leather_Contour] OR
`TrimsILeather_Suede]; "Subgrouping of leather trim
`types"
`NEW: Leather_Trim++ Trimcolor[Pamir] OR
`TrimColor[Buffalo]; ”Subgrouping of leather trim
`color"
`IMPOSSIBLE(AirCondition, Auto_AirCon);
`A:
`B- Models[Turbo_Cabriolet —+ Engine[turbo] AND
`Metallicpaints AND Leather_Trim AND Cruise_Control;
`C&D: Models[Cabriolet]—+ Engine[e21i] AND NOT
`TrimColortMarine];
`StandardPaints[Cherry_Red] OR
`StandardPaints[Tallaga_Red] OR
`MetallicPaints[citrin_Beige] OR
`MetallicPaints[Scarabe_green]—+ NOT
`TrimColor[Marine];
`F: MetallicPaints[citrin_Beige] OR
`MetallicPaints[Platana_Grey]—+ NOT TrimColor[Puma];
`Engine[turbo] —+ ABS_Brakes;
`G:
`H: Modelleabriolet] OR ModelsITurbo_Csbriolet] —+ NOT
`Sunroof;
`NEW: MetallicPaints OR StandardPaints; ”You must pick one
`type of paint"
`Delivery_Time == 14 * Models[Saab_900] + 21 *
`Models[Cabriolet] + 35 * ModelstTurbo_Cahriolet];
`21's) WARNING (NOT Air_Ba.g AND NOT ABS__Brskes);
`
`
`E:
`
`I:
`
`
`
`J
`
`
`
`.
`
`Figure 4. Saab configuration constraints at the (a) application level and (b) system level.
`
`Color of the type OneOf.
`o The available standard paints are cirrus
`white, black, embassy blue, cherry red,
`and talladega red. They are declared as
`one object StandardPaints of the
`type AtMostOne.
`o The available metallic paints are citrin
`beige, platana grey, le mans blue, scarabe
`green, and monte carlo yellow. They are
`declared as one object Metallic—
`Paints of the type AtMostOne.
`o The object Leather_Trim groups the
`objects that are related to leather features
`such as trim and trim color. It is declared
`
`as an object of the type Single.
`0 An object that does not relate to physical
`items is Delivery_Time. It is declared
`as an object of the type Enum.
`
`Several resources are declared in a
`database form. The declared resources
`are Price, Weight, and Horsepower.
`The declared menus are Accessories,
`Trims, Paints, and Accessories at
`Dealer.
`
`Configuration constraints. Figure 4a shows
`some application-level constraints for Saab
`configuration. The application-level con-
`straints can be interpreted into the system-
`level constraints. Figure 4b shows some sys-
`tem—level constraints.
`
`
`
`Note the almost one—to—one correspon-
`dence between the written guidelines (the
`application‘level constraints) and the system-
`level constraints. These constraints use the
`declared as an object Models of the type
`object identifiers. Only a few new extra con—
`OneOf.
`straints have been added to represent the
`. The four engines are the 2.0i, 2.1i, 2.08,
`and Turbo. They are declared as one whole meaning of the constraints at the appli-
`object Engine of the type Oneof .
`cation level. The system—level constraints are
`o The available accessories are automatic
`intuitive and very readable.
`gearbox, ABS brakes, air bag, air-condi-
`Figure 5 shows the Saab objects and con-
`tioning, audio system, automatic air—con-
`straints using the Definer.
`ditioning, electric mirrors and windows,
`Saab configuration. Figure 6 shows the sta-
`and cruise control. These are declared as
`tus of the Saab configuration process through
`eight objects of the type Single.
`the Customizer. The user can decide the lay-
`0 The available sunroofs are manual steel,
`out of the selection interface when creating
`electric steel, and electric glass. They are
`the product model with the Definer. The sys-
`declared as one object Sunroof of the
`tern makes deductions for selection based on
`type AtMostOne.
`the constraints, corresponding to the user
`0 The available trims are velour jet-tuff
`decisions. Selections can be made by the user
`horizon, velour pique parallel, leather
`(the light-green checks in Figure 6) or by
`contour, and leather suede contour. They
`Model object and resource declarations.
`the system (the dark—green checks). The
`are declared as one object Trims of the
`First, modeling engineers declare objects
`resources are calculated and updated simul—
`type OneOf .
`through the Definer.
`taneously while decisions on selections are
`o The available trim colors are labrador,
`.
`being made. System functions such as reset,
`.marine, puma, angora, buffalo, and pamir.
`0 The three models are the Saab 900, Cabri-
`olet, and Turbo Cabriolet. They are
`They are declared as one object Trim— default, undo, andfinish let the user carry out
`
`38 IEEE INTELLIGENT SYSTEMS
`
`that merely goes through a list of program—
`ming steps.
`
`CCII' configuration Wil'h
`sulesPLIlS
`
`Now let’s look at a specific application of
`salesPLUS. The configuration problem is
`from the 900 series models of 1992 Saab
`automobiles. We’ll consider the objects
`and constraints in depth. We’ve omitted some
`issues related to the Definer’s graphical
`interface, such as menu positioning, 1]), but-
`ton names, descriptions, object IDs, and
`languages.
`
`
`
`
`
`
`
`5
`
`

`

`configuration without worrying about con—
`figuration correctness and consistency.
`
`BASED ON OUR ACHlEVEMENTS
`with salesPLUS (see the sidebar for two
`other successful applications), we plan to
`continue our research into computer—sup-
`ported product development. We’ll enhance
`the problem—solving ability and system func-
`tionality of salesPLUS, to cope with various
`configuration problems throughout product
`development. Our product will be a solution
`that can cover a wider range of applications,
`spanning from front—office business to back—
`end engineering. Our goal is to make the con-
`figuration system an integrated solution in a
`common product-development environment.
`Toward that end, our next step will be to
`emphasize system and data integration, so
`that product information and solutions can
`be shared, exchanged, and applied among
`different tools in the individual product-
`development stages. E
`
`References
`
`1. HI. Skovgaard, “A New Approach to Prod-
`uct Configuration,” Proc. ilce ’95: Third Int’l
`Conf. Integrated Logistics & Concurrent
`Eng., 1995, Pp. 197—204.
`
`2. B. Victor and A. Boynton, Invented Here:
`Maximizing Your Organization’s Internal
`Growth and Profitability, Harvard Business
`School Press, Boston, 1998.
`
`3. K]. MacCallum, “Does Intelligent CAD
`Exist?” Artificial Intelligence in Eng. , Vol. 5,
`No. 2, Apr. 1990, PP. 55—64.
`
`4. CJ. Thornton and B. du Boulay, Artificial
`Intelligence through Search, Kluwer Acade-
`mic Publishers, Dordrecht, The Netherlands,
`1992.
`.
`
`5. B. Yu, “A Virtual Configuration Workbench
`for Product Development," PhD Thesis, Univ.
`of Strathclyde, Dept. of Design, Manufacture,
`and Eng. Management, Glasgow, Scotland,
`1996.
`
`
`
`,
`t
`
`Aulnmlnn gurimx
`ABE Broken
`Alr an:
`Air Cnnnliinn
`Audio Syuirrn
`Autumn“: Aireon
`Electric mlmirn
`Cruise Guntrnl
`€51 Plinll
`Merrill: Paint:
`‘ gBinnfleniPaints
`.
`Mnlll Faint Mn
`Trim Cnlnr
`Luther Trim
`49:) Men-Inne- It Denial
`
`anmrllrnlhgj‘canlouiiqfi Tnm|[LIIthq_LSuld
`’
`7
`Luther Trim 0 TnmCol
`‘
`7 fr j: -
`W
`Mntnl PliniT I v MItIiiiePeimu
`Moduli Turhn Orbitalet
`> E
`Inn luihn AND MIlIllIcPainil AND Luther Trim AND 0mm
`
`Envlnoturtin -> ABE Evlknl
`V
`MndnlnCabrtuill on Mndnl-Turhu Clbrioint NOTroni‘ '
`Wlmin NOT Air Bn- and NOT ABS Baku
`MIlIlllcPalnlI xor SilndlrdPIintI
`new. Timon-H'MndIIISAAB 9m +21 'Mndeil abdol +35‘Mndli Tilt-11..
`IMPOSSIBLE Air Condiilon Auto AhCen
`
`,
`
`,
`
`7
`
`.
`
`_
`_
`
`
`
`
`
`Figure 6. Saab configuration, using the salesPLUS Customiier.
`
`7. M. Shanahan and R. Southwick, Search,
`Inference and Dependencies in Artificial
`Intelligence, Ellis Horwood Ltd., Chichester,
`UK, 1988.
`
`8. G. Muller, “On the Technology of Array—
`based Logic,” PhD Thesis, Technical Univ.
`of Denmark, Dept. of Electric Power Eng.,
`Lyngby, Denmark, 1995.
`
`
`
`Hans Jorgen Skovgaard is the vice president for
`configuration development at Baan Front Office
`System NS and is the chief architect on the con-
`figuration product salesPLUS, with whose devel-
`opment he has been involved since 1990. His
`research interests include black-box constraint
`Bei Yu is a research engineer at the Configuration
`Competence Centre, Baan Front Office Systems.
`solvers and declarative language design. He
`received his BSc in electronic engineering from
`She has been doing research in product configu-
`ration since l992. Her research interests include
`Odense Polytechnic, Denmark, and his MSc in
`product modeling, the configuration process, con—
`artificial intelligence from University of Edin-
`figuration technology, and artificial intelligence.
`burgh, Scotland. Contact him at Baan Front Office
`She received her BSc in computer science and PhD
`Systems, Horkaer 12A, DK—273O Herlev, Copen-
`5. G. Moller, “Signal Processing Apparatus and
`Method," Patent W0 90/9001, 1989.
`hagen, Denmark; hjskovgaard@baan.com.
`in product configuration from the University of
`
`39
`JULY/AUGUST i998
`
`StIathclyde, Scotland. Contact her at Baan Front
`Office Systems, Hnrkaer 12A, DK-2730 Herlev,
`Copenhagen, Denmark; byu@baan.com.
`
`
`
`
`
`6
`
`

`

`
`
`
`
`
`
`
`
`
`Two successful applications of solesPlllS
`
`salesPLUS has been successfully applied to many applications, such
`as the discrete manufacturing of pumps, robots, and vehicles; telecom-
`munications; and high-tech services. We’ll now focus on two real-
`world applications.
`
`Audiovisual-system configuration
`
`Bang & Olufsen manufactures high—end consumer audiovisual
`equipment (FigureA shows an example). Their products are marketed
`globally by approximately 1,500 prequalified retail outlets. Their 1996
`turnover was approximately $450 million. In cooperation with a num-
`ber of universities and other European organizations, B&O developed
`the initial concepts behind salesPLUS,
`
`The problems. B&O’s audiovisual systems suffered from product
`complexity. This led to a long delivery time and lower dealer loyalty
`because of fear of market competition. Dealers could not handle the
`configuration complexity in the short delivery time that customers
`demanded. Also, order errors were normal; dealers usually sold incom-
`patible components or were missing components. The transportation
`and resupply costs associated with these err