CONFIGURATION
`
`This material may be protected by Copyright law (Title 17 U.S. Code)
`
`A Configuration Tool to
`Increase Product
`Competitiveness
`
`Bei Yu and Hans Jorgen Skovguurd, Buun 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-
`termining 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:
`
`They can’t handle product complexity
`well enough. Complicated product struc-
`tures with numerous relationships lead to
`the hard configuration problems. No real
`solutions exist yet for these problems-
`that is, no approach to product configu-
`ration can significantly decrease product
`complexity.
`They can’t support configuration mainte-
`nance well enough. Although several the-
`Page 1 of 8
`
`43
`
`THE SALESPL US PRODUCT- CONFIGURATION TOOL
`
`EFFECTIVELY SOLVES COMPLEX CONFIGURATION PROBLEMS,
`REDUCING cosrs WHILE MEETING CUSTOMER EXPECTATIONS
`
`"
`
`INREAL-WORLD APPLICATIONS.
`
`oretical approaches are available, they are
`impractical, because of the limitations of
`time, computer speed, memoiy, and so on.
`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 performance 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
`
`salcsPLUS is based on the concept of mass
`customization—that is, product configuration
`
`1094-7167/98/$10.00 © 1998 IEEE
`
`generates customized solutions based on a
`standard product or product model? 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 starts out from a precompiled rep-
`resentation and is, as expected, several times
`faster, but maintenance savingsf‘ The main
`objectives of sa1esPLUS are to
`
`0
`
`ensure configuration correctness—that is,
`100% accuracy on the valid configuration
`solutions;
`develop an effective approach for han-
`dling configuration consistency;
`handle configuration constraints;
`overcome the limitations of product-
`knowledge maintainability; and
`support the whole development of a con-
`figuration application—that is, product
`modeling and configuration—without
`requiring programming skill.
`
`FORD 1313
`IEEE INTELLIGENT SYSTEMS
`
`Page 1 of 8
`
`FORD 1313
`
`

`
`For the whole life cycle of product de-
`velopment, configuration consists of two
`aspects: configuration design and configu-
`ration maintenrznce.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 1). 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
`
`of several submodels; for example, a train
`consists of several cars. Objects might vary
`from physical parts (such as a screw), to sub-
`assemblies (for example, a speaker), to whole
`products (perhaps a car radio system).
`Page 2 of 8
`JULY/AUGUST 1998
`
`Modeling
`
`Configuration
`
`Figure l.The configuration-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:
`
`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].
`Interval objects let you can divide a
`numeric range into a rfumber of consec-
`utive nonoverlapping subintervals. With
`these objects, you can reason about the
`inteival, not the exact value.
`Oneof objects have mutually exclusive
`elements. They are used to group a set of
`components from which one must be
`selected.
`'
`
`AtMostOne objects let you select one
`element at most. Otherwise, they are sim-
`ilar to Oneof objects.
`Anyof objects let you select no elements
`
`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.
`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.
`
`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:
`
`User
`selections
`
`End-userapplication-Customized
`
`FORD 1313
`
`35
`
`Figure 2. A configuration scenario in salesPLUS.
`
`Page 2 of 8
`
`FORD 1313
`
`

`
`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) I <—> (bi—irnplication). The con-
`stants TRUE and FALSE can also be used.
`
`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
`
`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:
`
`product model. This is important for an inte-
`grated development environment; moduliz-
`ing a large product into manageable modules
`can reduce product complexity.
`
`Allequal (The elements must be either
`all TRUE or all FALSE.)
`Oneof (There must be exactly one TRUE
`element.)
`AtMost0ne (There must at most be one
`TRUE element.)
`AtLeastOne (There must at least be
`one TRUE element.)
`Impossible (The elements cannot all
`be TRUE.)
`
`set physical
`constraints
`Arithmetic
`(numerical) lirnits-—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
`[cornpare]), >= (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.
`
`Some objects are measured by quantity,
`which can be assessed. Typical resources for
`such objects are product price, manufactur-
`ing cost, power, space, and delivery time.
`Resources are typically referenced in exter-
`nal tables, fixed or online, because they
`change often——for example, price lists,
`which vary per country. Database links can
`Page 3 of 8
`
`36
`
`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.
`
`Freedom to make changes. In configuration,
`changes of previous choices are typical and
`
`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 I
`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-
`
`tornizer 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 tool should be
`able to build a feature-rich product, should
`be based on an open architecture, and should
`easily integrate with other enterprise appli-
`cations. We’ve achieved this in salesPLUS
`through product modulization and the incor-
`poration of well-defined integration points.
`This minimizes the effort required to imple-
`ment the product in almost any environment.
`For example, we’ve developed an add-in
`interface to support customers’ special
`
`FORD 1313 /
`
`IEEE INTELLIGENT SYSTEMS
`
`Page 3 of 8
`
`FORD 1313
`
`

`
`Inference engine design. The inference
`engine’s objective is to handle constraints
`such that correct configuration solutions can
`be derived as quickly as possible. It is an
`effective constraint-based problem solver
`with our patented technology5 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-
`dant-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 vatious constraints, and the prod-
`uct model’s level of detail cause this com-
`
`plexity. This kind of problem leads to a large
`Search space for solutions. Although some
`algorithms such as forward-checking perform
`better
`than traditional backtracking ap-
`Pa e4of8
`lit/AUGUST I998
`
`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 Max'1‘ime time—lin1it 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
`
`or two seconds; this limit is independent of
`the platform. In our experience, the more
`selections the user makes, the less time the
`
`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. Ifthe 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 alternatives 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 airay—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-
`tion. Referencing the truth table at runtime
`lets the configuration engine deduce all the
`consequences faster than would an engine
`FORD 131
`37
`
`Page 4 of 8
`
`FORD 1313
`
`

`
`Color of the type Oneof.
`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.
`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.
`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.
`An object that does not relate to physical
`items is De1ivery_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, andAccessories 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—leve1 constraints) and the system-
`level constraints. These constraints use the
`
`object identifiers. Only a few new extra con-
`straints have been added to represent the
`whole meaning of the constraints at the appli-
`cation level. The system—level constraints are
`intuitive and very readable.
`Figure 5 shows the Saab objects and con-
`straints using the Definer.
`
`Saab configuration. Figure 6 shows the sta-
`tus of the Saab configuration process through
`the Customizer. The user can decide the lay-
`out of the selection interface when creating
`the product model with the Definer. The sys-
`tem makes deductions for selection based on
`
`the constraints, corresponding to the user
`decisions. Selections can be made by the user
`(the light-green checks in Figure 6) or by
`the system (the dark-green checks). The
`resources are calculated and updated simul-
`taneously while decisions on selections are
`being made. System functions such as reser,
`default, undo, andfinish let the user carry out
`FORD 1313
`IEEE INTELLIGENT SYSTEMS
`
`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—|iter 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 forthe 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.
`
`AB
`
`:
`:
`
`. C:
`D:
`E:
`F:
`G:
`H:
`I:
`
`J:
`(a)
`
`NEW: Leather_Trim(-—> Trims [Leather_Contour] OR
`Trims [Leather_Suede] ; "Subgrouping ‘of leather trim
`types"
`NEW: Leather_Trim(—) Trimcolor,[Pa.mir] OR
`TrimCo1or[Buffa1o]; "Subgrouping of leather trim
`color"
`
`- Im.=ossIsi.E(Aircondition, Auto_AirCon) ;
`Models[Turho_Cabrio1et —> Engine[turbo] AND
`Meta11icPaints AND Leather_Trim AND Cruise_Contro1;
`Models [Cabriolet] —> Engine[e21i] AND NOT
`Trimcolor [Marine] ;
`StandardPaints [Cherry_Red] OR
`_ Sta.ndardPaints[Ta11,aga_Red] OR
`Meta11icPaints [Citrin_Beige] OR
`Meta11icPaints_ [Scarabe_green] —> NOT
`Trimcolor [Marine] ;
`Meta.11icPa:i.nts [Citrin_Beige] OR
`Meta11icPaints[P1atana_Grey] -9 NOT Tr:i.mCo1or[Puma] ;
`Engine[turbo] -a ABS_Brakes;
`Mode1s[Cabrio1et] OR Mode1s[Turbo_Cabrio1et]
`Sunroof ;'
`'
`Mel:a11:i.cPaints OR StandardPaints; "You must pick one
`type of paint"
`'
`,
`'De1ivery_Time == 14 * Mode1s[Sa.ab_900] + 21 *
`Mode1s[Cabrio1et] + 35 * Mode1s[Turbo_Cabrio1et];
`WARNING (NOT Air_Bag AND NOT ABS_Brakes) ;
`
`-9 NOT
`
`,
`
`J:
`(b)
`
`Figure 4. Saab configuration conslruinls at the (u) application level and (b) system level.
`
`that merely goes through a list of program-
`ming steps.
`
`declared as an object Models of the type
`Oneof.
`
`Cur configuration with
`salesPllJS
`
`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, ID, but-
`ton names, descriptions, object IDs, and
`languages.
`
`Model object and resource declarations.
`First, modeling engineers declare objects
`through the Definer.
`
`- The three models are the Saab 900, Cabri-
`olet, and Turbo Cabriolet. They are
`Page 5 of 8
`
`83
`
`The four engines are the 2.0i, 2.li, 2.0S,
`and Turbo. They are declared as one
`object Engine of the type Oneof.
`The available accessories are automatic
`
`gearbox, ABS brakes, air bag, air-condi-
`tioning, audio system, automatic air—con-
`ditioning, electric mirrors and windows,
`and cruise control. These are declared as
`
`eight objects of the type Single.
`The available sunroofs are manual steel,
`electric steel, and electric glass. They are
`declared as one object Sunroof of the
`type AtMostOne.
`The available trims are velour jet-tuff
`horizon, velour pique parallel, leather
`contour, and leather suede contour. They
`are declared as one object Trims of the
`type Oneof .
`The available trim colors are labrador,
`marine, puma, angora, bufialo, and parnir.
`They are declared as one object Trim-
`
`Page 5 of 8
`
`FORD 1313
`
`

`
`Mm Palm T 0 0 MIlI|I|ePnlnII
`
`Mulnu
`Moumcahnom -> Enlnultl AND NDT‘lHm
`Modulu SAAB 9120 -> NOT MItaI|IcF||nlI
`O _
`
`"
`
`'
`
`, W :_,
`
`_
`__
`
`'
`
`' I-31 Aceulnrln
`Aulnmntlv: unrhnx
`ABE Erika:
`Alt Emu
`Alr cnndlllnn
`Audln Byllnm
`Aulnmulle Alrcnn
`Elnellln mlmm
`Cruluu Gunhnl
`Pnlnll
`Bhndnrd Pulnln
`Mmlllv: Palm
`Mull! Pllnl M):
`
`ETrlm Cnlnr
`
`c‘.
`l T erg?
`l
`l.{ (v.-l
`.I
`I.
`I
`
`r t
`
`lle il 3l
`
`Figure 6. Saab configuration, usin he su|esPLUS Customiier.
`
`configuration without worrying about con-
`figuration correctness and consistency.
`
`BASED ON OUR ACHIEVEMENTS
`with sa1esPLUS (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. H.J. Skovgaard, “A New Approach to Prod-
`uct Configuration,” Proc. ilce ’95: Third Int’l
`Con)‘. Integrated Logistics & Concurrent
`Eng., 1995, pp. 197-204.
`
`. B. Victor and A. Boynton, Invented Here:
`Maximizing Your 0rganizatian’s Internal
`Growth and Profitability, Harvard Business
`School Press, Boston, 1998.
`
`. K.J. 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.
`.
`
`7. M. Shanahan and R. Southwick, Search,
`Inference and Dependencies in Artificial
`Intelligence, Ellis Horwood Ltd., Chichester,
`UK, 1988.
`
`8. G. Mgztller, “On the Technology of Array-
`based Logic,” PhD Thesis, Technical Univ.
`of Denmark, Dept. of Electric Power Eng.,
`Lyngby, Denmark, 1995.
`
`Strathclyde, Scotland. Contact her at Baan Front
`Office Systems, Hetrkwr 12A, DK-2730 Herlev,
`Copenhagen, Denmark; byu@baan.com.
`
`Hans Jargen Skovgaard is the vice president for
`configuration development at Baan Front Office
`System A/S 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
`solvers and declarative language design. He
`received his BSC in electronic engineering from
`Odense Polytechnic, Denmark, and his MSc in
`artificial intelligence from University of Edin-
`burgh, Scotland. Contact him at Baan Front Office
`Systems, Horkaar 12A, DK—273O Herlev, Copen-
`hagen, Denmark; hjskovgaard@baan.com.
`
`FORD 131339
`
`. B. Yu, “A Virtual Configuration Workbench
`for Product Development,” PhD Thesis, Univ.
`of Strathclyde, Dept. of Design, Manufacture,
`and Eng. Management, Glasgow, Scotland,
`1996.
`
`. G. Mgzlller, “Signal Processing Apparatus and
`Method,” Patent WO 90/9001, 1989.
`
`Bei Yu is a research engineer at the Configuration
`Competence Centre, Baan Front Office Systems.
`She has been doing research in product configu-
`ration since 1992. Her research interests include
`product modeling, the configuration process, con-
`figuration technology, and artificial intelligence.
`She received her BSc in computer science and PhD
`in product configuration from the University of
`
`P
`"lY/Aucust
`
`93
`
`6of&
`
`Page 6 of 8
`
`FORD 1313
`
`

`
`The results. B&O’s implementation of salesPLUS has directly and
`indirectly produced these improvements:
`
`0 Average speaker sales have increased from 2.1 to 2.8 per system.
`0 Errors in orders have decreased by 4%, saving $5.6 million per
`year.
`
`Electronic distribution of sales and product documentation through
`salePLUS has saved more than $300,000 per year.
`The use of service personnel has decreased, saving more than
`$130,000.
`Stock levels have decreased from $50 million to $12.5 million.
`Education days have decreased from 5,000 to approximately 2,500
`per year.
`Total sales have increased, reflecting higher dealer loyalty.
`
`Future plans. The system has been enhanced into a multimedia config-
`uration and sales tool and will soon be launched as an interactive sell-
`ing too]. That is, the customer will be able to directly access the system
`to configure his or her products. Also, B&O plans direct electronic
`transmission of information such as bills of materials from sales-order
`
`Two successful applications of salesPLUS
`
`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 (Figure A 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 t