CONFIGURAfi()N
`
`:
`
`'
`
`:
`
`-
`
`An lnclusfriai-Sbengtlt
`Description &ogic-Basecl
`Configurator Platform
`
`hborah L Mchinness and Jon R. Wright, AT&T Labs-Research
`
`MoDERN TELECOMMUNICA(cid:173)
`tions equipment is highly modular and can
`scale to a wide range, of applications. Usu(cid:173)
`ally, the equipment's cost and complexity
`requires that it be manufactured-to-order, or
`at least assembled-to-order. In this context,
`orders double as specifications, describing
`what should be manufactured as well as how
`the product should be installed, Producing a
`correct and complete order for such equip(cid:173)
`ment can be challenging when requirements
`are incomplete, inconsistent, or when the
`finalproduct is large and complicated , A
`good order is technically correct and meets
`customer requirements for network capacity
`and growth without over-engineering. In(cid:173)
`complete configurations can lead to cost
`overruns if the missing elements are discov(cid:173)
`ered during manufacturing. If they are not,
`faulty products can result. Either way, the
`customers are unhappy,
`We have tackled the configuration problem
`for a number of large telecommunications
`products sold by AT&T and Lucent Tech(cid:173)
`nologies. Our Prose configurators are based
`on CLASSIC, 1 a description logic-based
`knowledge representation system developed
`at AT&T Bell Laboratories. CLASSIC is
`freely available for academic purposes, and
`commercially available for other purposes. a1
`http :llwww. research. att. comlswltoolsl
`
`USING DFSCR1n10N LOGICS AS A FOUNDATION, THE
`AUTHORS DEVELOPED COMMERCIAL CONFIGURATORS FOR
`
`LARGE, COMPLEX TELECOMMUMCATIONS PRODUCTS. I
`
`classic. AT&T has distributed CLASSIC to
`more than I 00 universities; itis also in use for
`internal projects at AT&T, Lucent, and NCR.
`Implementations are available in LISP, C++,
`and C.
`CLASSIC is part of a description logic
`family that was developed with the goal of
`balancing usability, expressivity, and com(cid:173)
`plexity. We have found it to be well suited to
`our configurator needs. Because it attempts
`to provide predictable performance in all
`cases, CLASSIC is less expressive than many
`description logic systems, but it has been
`widely used in both industrial applications
`and academic systems.
`Some of our configurators have been in
`use since 1990. They h ave processed more
`than $4.5 billion in orders and have docu(cid:173)
`mented many benefits, including reduced
`order processing time, reduced staffing, and
`product-knowledge consistency checking.
`
`Background
`
`We began developing a configurator based
`on description logic in 1988 when we were
`approached by a group of system engineers
`involved in the re-engineering of an impor(cid:173)
`tant business process, which at AT&T is
`sometimes called the Engineer, Furnish, and
`Install process. The EF&I process begins
`with customer-sales interaction and ends
`when a product is successfully manufactured
`and installed . T he engineering group had
`identified product configuration as key to
`EF&I business processes.
`Among the most important goals of this
`re-engineering project were:
`
`• decreasing the time between new equip(cid:173)
`ment sales and installation, and
`reducing the rework cansed by mistakes
`and inaccuracies in incoming orders.
`
`•
`
`JUlY / AUGUST 1991
`
`1094-7 t67/98/S l0.00@ t998 JEEE
`
`69
`
`FORD 1011
`
`Page 1 of 9
`
`

`
`DS3
`lntertace-32
`Module
`
`Blank
`panel
`
`Figure I. The hierordlicol structure of o DACSIY· 2000 crQSS·tonnect syslem ..
`
`With this in mind, we developed a proto(cid:173)
`type configurator for the Fr Series G fi ber(cid:173)
`optic transmission system. TheFT Series G
`configurator was never released, but it was
`effective enough that a software development
`team was assigned to the project in early
`1990. The project, now called Prose (prod(cid:173)
`uct offerings expertise), delivered its first
`configuration to AT&Ts Merrimac Valley
`Works in Andover, Massachusetts, later that
`year. We assisted our software development
`collaborators in eventually developing and
`deploying 18 Prose configurators, and they
`have played an important supporting role in
`·
`re-engineering the EF&I process.
`
`Early lessons. Over the years, we learned
`many lessons. Two early discoveries were
`particularly important to our success. First,
`realizing that product knowledge was scat(cid:173)
`tered across different organizations, we
`decided to merge the product know ledge into
`a knowledge base that was both consistent
`and commonly accessible.
`Second, given the dynamic nature of
`complex telecommunications products, we
`quickly realized that product know ledge inai.n(cid:173)
`tenance would be an ongoing concern. Also,
`tl1ekey products from a business standpoint(cid:173)
`new products and top sellers-change the
`most. During the 10 years we worked on con(cid:173)
`figurators, we observed change rates as high
`as 40 to 50% per year for some products (as
`measured by turnover and changes in config(cid:173)
`uration rules and constraints). Consequently,
`knowledge acquisition and maintenance were
`high on our list of problems to solve, and
`drove much of the work we did on technical
`problems.
`Many people involved in the EF&I process
`need to understand the product knowledge
`
`the whys and
`underlying a specific order-
`why nots of a pa,rti.cular product configura(cid:173)
`tion. This need overrode many oilier issues for
`tlS. Given this, one member of our team devel(cid:173)
`oped some novel approaches to explanation
`and troth maintenance in description logics.2.3
`
`The knowledge problem. ln real-world
`applications, success seldom comes from
`focusing solely on technical issues. In fact,
`to solve knowledge acquisition and mainte(cid:173)
`nance problems for the.Prose configurators,
`we had to consider the context in which
`knowledge originated and was distributed
`throughout the EF&I business process. This
`context imposed specific requirements on ow·
`configuration platform.
`We selected description logics as a basis
`for our work because the field has several
`important features for addressing configura(cid:173)
`tion problems, including:
`
`• object-oriented modeling;
`• mle r.epresentation, organization, and
`triggering;
`• . active inference and knowledge comple(cid:173)
`tion;
`• explanation, product training, and help(cid:173)
`desk support;
`• ability to handle incrementally evolving
`specifications;
`• extensible schemas;
`•
`reasoning mechanisms that handle in(cid:173)
`. complete or ambiguous information;
`inconsistency detection, en-or handling,
`and retraction; and
`• modularity.
`
`•
`
`These needs are common in. many com~
`plicated deductive tasks, but we believe there
`were particularly critical in our configurator
`
`70
`
`applications. In particular, the fact that
`knowledge was distributed and used by dif(cid:173)
`ferent people in different geographical loca(cid:173)
`tions produced some special challenges.
`We are not alone in using description log(cid:173)
`ics for configuration. Ford Motor Company,
`for example, has an automotive configura(cid:173)
`tor4 based on another description logic. To
`our knowledge, we have developed the first
`commercial de$cription !ogic-bas~ ~nfig­
`urator, as well as the longest. lived· and
`arguably most significant description logic(cid:173)
`based contigurator environi:nent. The side(cid:173)
`bar, "Description logics" offer further infor(cid:173)
`mation on the method itSelf. Following; we
`. offer a simple e'xar.llple mJd, use it as a con(cid:173)
`text to explore each .Of the description logic
`features above.
`
`DACS IY·2000
`
`For efficiency, telecommunications net(cid:173)
`works bundle individual phone calls into
`composite signals known as DS 1 and DS3
`signals. These are standards in the US do(cid:173)
`mestic market. lLLS! as indi vidnal phone calls
`are switched by switching machines, higher
`level signals are also switched, in a manner
`of speaking: software in a cross-connect sys(cid:173)
`tem controls the signals and can reroute them
`in case of network congestion, outage, and
`soon.
`As an example bere, we chose our
`DACS IV-2000 cross-connect system.
`Althot1gh simplified for our discussion, the
`example covers a repre.~entation and rea(cid:173)
`soning structure that is isomorphic to our
`deployed configurators.
`Figure 1 shows the basic physical stwc(cid:173)
`. ture of the DACS IV-2000. Essentially, it is
`composed of equipn:~ent bays, each of which
`has shelves for electronic assemblies, which
`in turn have slots for circuit-packs (not shown
`in Figure 1). The equipment is modular and
`thus engineers can add new functionality and
`capacity to existing systems simply by
`adding circuit packs.
`A DACS IV-2000 has a single switch bay
`and up to eight interface bays_ The intelface
`bays connect to the outside world (incoming
`and outgoing signals) and the switch bay
`"switches" tile signals under software control.
`A more detailed description of the DACS
`IV-2000 configuration is available. 5 We also
`have built a configurator demo for stereo
`equipment 6 and have recently ported it to the
`Web. For most people, this is a more acces-
`
`IEEE INTtLUGINT SYSTEMS
`
`FORD 1011
`
`Page 2 of 9
`
`

`
`sible domain than teleconununica.tions, yet
`is reasoning isomorphic to that of the de(cid:173)
`ployed telecommunications configurators.
`The demo is available at http://taylor.es.
`vassar.edulstereo-demol.
`
`Description logics and the
`DACS system
`We now have more than eight years' expe(cid:173)
`rience with deployed configurators based on
`description logics. Most of the telecommu(cid:173)
`nications equipment we encounter has sev(cid:173)
`eral levels of ruerarcrucal nesting: circuit
`packs, assemblies, and bays or frameworks
`for the assemblies; individual frameworks
`are themselves composed into higher level
`entities, fiber-optic links, wireless cell sites,
`and so on. The ru.erarchical structure inherent
`in most teleconununications equipment lends
`itself narurally to object-oriented methodol(cid:173)
`ogy and, in particular, to declarative tech(cid:173)
`niques. Thus, in producing a configuration,
`we are not so much interested in how a
`piece of equipment works, as we are in its
`structure: the components and their inter(cid:173)
`relationships.
`
`Object-oriented modeling. Configuration
`applications usually have some sort of struc·- .
`tured domain. Our DACS IV-2000 application
`has a knowledge base that includes a concept
`taxonomy and instance descriptions. Figure 2
`shows a piece of the concept taxonomy. At the
`top is a general concept, DACS-IV-THING,
`with subconcepts DACS-IV-BAY, DACS(cid:173)
`IV-SHELF, and DS3-EQUIPMENT. At the
`bottom are DS3-EQUIPMENT. DS3-32-
`SHELF, and COMBO-BAY. Subconcepts are
`related to parent concepts by an "isa" relation
`(denoted by dark arrows), which means, for
`example, that anything that is a DS3-32-
`SHELF is also DACS-JV-SHELF.
`Concepts are structured descriptions and
`can have many encoded restrictions. Lower
`level concepts inherit restrictions from higher
`level concepts, but contain additional restric(cid:173)
`tions used to distinguish them from their par(cid:173)
`ents. Hence, lower level concepts are more
`specific and higbe( level concepts are more
`general. The inheritance rue(a.rchy encodes
`restrictions at the most abstract level possi(cid:173)
`ble. Like most description logics, CLASSIC
`supports strict inheritance, and thus restric(cid:173)
`tions represent true statements about a con(cid:173)
`cept and all its subconcepts. The most gen(cid:173)
`eral concept in Figure 2, DACS-IV-THING,
`
`JUlY/ AUGUS11998
`
`contains information that is colllinon to all
`of DACS-IV-THING's subconcept~. Such
`information might include knowledge about
`price-that a price exists, is non-negative,
`has a certain upper bound, and so on. More
`specific information that distinguishes com(cid:173)
`ponent classes like DS3-32-SHELF from
`DS3-EQUIPMENT is associated with more
`specialized concepts, such as specific price
`ranges.
`The COMBO-BAY concept illustrates
`some of tbis structure. It has roles for each of
`the foil\' shelves in the bay, and for additional
`equipment such as cabling. Each role has:
`
`t
`
`t
`
`a number resttiction, which restricts the
`numberof"fillers" than the role can con(cid:173)
`tain; and
`a value restriction, which limits the fillet'S
`to a cet1ain "type" and is involved in p(o(cid:173)
`pagation (more on this later).
`
`Instances, often called individuals, are
`si.milar to objects in object-oriented lan(cid:173)
`guages. In Figure 2, they appear as circles
`alfld their labels have numbers attached. Each
`individual has a unique identity. Individuals
`e;an inherit from concepts but not od1er indi(cid:173)
`viduals. We distinguish instance inheritance
`
`71
`
`FORD 1011
`
`Page 3 of 9
`
`

`
`from concept inheritance in our diagrams by
`using different arrows. Roles define relations
`between individuals. When one individual is
`related to another we include an appropri(cid:173)
`ately labeled line in our diagrams-in Fig(cid:173)
`ure 2, the Bay#9 and Shelf#19 individuals
`are related by the thirdshelf relation.
`One reason that we organize the knowl(cid:173)
`edge base in this fashion is that it simplifies
`summarization. Because CLASSIC recog(cid:173)
`nizes the class membership of all its instances,
`we can retrieve and count all the instances of
`DSl-ASSEMBLY for summary reports and
`the like after configuration is completed.
`We created the DACS IV-2000 knowledge
`base working with a domain expert. In the
`beginning, the database of instance informa(cid:173)
`tion, such as particular circuit packs and their
`specifications, was hand-compiled. Later in
`the project, we developed a domain-specific
`translator for our product experts to use. The
`translator was based on a notation that prod(cid:173)
`uct experts and technical consultants used to
`express configuration rules and constraints.
`The notation they were using was informal and
`imprecise, but after we sharpened it, it became
`the main vehicle for knowledge acquisition.
`
`Rule representation, organization, and
`triggering. Typically, a knowledge base con(cid:173)
`tains class rules and definitions. It's common
`to see constraints that :lpply across different
`structural components of a configuration. In
`our domain, for example, software has to
`match hardware. Thus, certain hardware
`selected in a DACS IV-2000 configuration,
`such as circuit packs for processing DS3 sig(cid:173)
`nals, might require a specific software release
`(sometimes called a "generic").
`Figure 3 shows a simple diagram sequence
`that illustrates how we use rules to implement
`such constraints. The top-level node in Figure
`3a (BAY-LINEUP) represents a concept def(cid:173)
`inition with two roles: software and inter(cid:173)
`face-bay. In addition, the interfacebay role has
`a value restriction-uppershelf[0-1]. In other
`words, any instance playing the role of inter(cid:173)
`face bay in the DACS-IV lineup cannot have
`more than one uppershelf. BAY-LINEUP has
`one subconcept, BAY-LINEUP-G2, which
`has an associated rule (indicated by the white
`arrow). Individuals have a unique identity and
`are numbered (Lineup#12 and Bay#27).
`Description logics are said to have active
`inference because they deduce the logical
`consequences of given information. Once a
`description logic system recognizes that an
`object is an instance of the rule's left-hand side,
`
`72
`
`Figure 2. Concept hierarchy for a small portion of the DACS IV-2000 knowledge base.
`
`the rule is triggered and asserts a new fact on
`the object. For example, suppose we add the
`information that the upper shelf ofBay#27 is
`filled with aDS3-SHELF (seeFigure3b). The
`filler could be any of type of DS3-SHELF.
`When this happens, the knowledge base rec(cid:173)
`ognizes that Lineup# 12 is an instance ofBAY(cid:173)
`LINEUP-G2 (Figure 3c ), because the precon(cid:173)
`ditions for it being a BAY-LINEUP-G2 have
`been met. Because a rule is associated with this
`new concept (indicated by white arrow), the
`knowledge base also asserts thatLineup#12is
`a BAY-LINEUP-G2 (Figure 3d). Conse(cid:173)
`quently, Lineup#12 acquires several new par(cid:173)
`ent concepts in this process. These new con(cid:173)
`cepts may provide more information about
`Lineup#l2, and the cycle of recognition and
`assertion can be repeated in a chaining fash(cid:173)
`ion until all possible information is derived?
`In the telecommunications domain, rules
`fall into two classes: hard and fast rules (such
`as auxiliary power supplies are required
`when capacity exceeds a given amount) and
`rules of thumb (such as one performance
`monitoring circuit pack per bay is usually(cid:173)
`but not always-sufficient). Because CLAS(cid:173)
`SIC does not allow default reasoning and
`exceptions, all products configured by the
`knowledge base must abide by the hard and
`fast rules; hence, the rules of thumb are uni(cid:173)
`versally enforced just like other rules. CLAS(cid:173)
`SIC does not support explicit defaults. If a
`default representation were available, we
`would have implemented our rules of thumb
`as defaults.
`In some cases, the Prose platform imple(cid:173)
`mented a form of defaults via its user inter(cid:173)
`face. This method is compatible with input
`
`completion, one of the simplest proposals for
`handling defaults in description logics. If the
`user does not specify certain input values, the
`system "completes" the input with pre(cid:173)
`selected default values. In another applica(cid:173)
`tion, we implemented the default information
`as a "guided system". Users could then chose
`to follow the rules of thumb by asking for a
`guided system or they could over ride this
`information by deleting the guidance request.
`
`Active inference and knowledge comple(cid:173)
`tion. After the interface guides the user
`through a few simple questions, the under(cid:173)
`lying description logic provides active infer(cid:173)
`ence. For example, users answer questions
`about the desired system capacity, as well as
`their preferences on a few high-level features,
`such as performance monitoring. With these
`inputs, the configuration application per(cid:173)
`forms a search using the CLASSIC knowl(cid:173)
`edge base to determine a range of solutions
`that satisfy these inputs. It also determines if
`follow-up questions need to be asked. The
`configurator then generates a complete (ab(cid:173)
`stract) product description.
`For example, imagine that the user chooses
`a capacity in terms of DS 1 and DS3 signals,
`but does not specify a particular level of qual(cid:173)
`ity. CLASSIC deduces the minimum number
`of circuit packs of each type that will meet
`these requirements, then adds shelves, bays,
`and cabling required to feed that equipment. A
`description logic-based system might also pre(cid:173)
`sent several abstract solutions. When the user
`selects one, the system might then ask for fur(cid:173)
`ther input-such as service quality informa(cid:173)
`tion-before completing the configuration.
`
`IEEE INTELLIGENT SYSTEMS
`
`FORD 1011
`
`Page 4 of 9
`
`

`
`CLASSIC calculates the logical implica(cid:173)
`tions (or deductive closure) of the informa(cid:173)
`tion users provide. The user can view the
`completed information on any component or
`the entire system by clicking an icon or other
`interface element.
`One way in which description logics
`achieve knowledge completion is to propa(cid:173)
`gate information from one instance to another
`via value restrictions. Figure 4 illustrates how
`this works. In this example, Shelf#53 and
`Shelf #61 are both instances of DS3-SHELF
`(Figure 4a). Bay#27 is a DS3-BAY that has
`inherited value restrictions for the upper(cid:173)
`shelf and lower-shelf roles such that any filler
`of the upper-shelf role must be a DS3-32-
`SHELF (that is, it has a capacity of 32 DS3
`signals) and any filler of the lower-shelf role
`must be a DS3-16-SHELF. When Shelf#53 is
`added to the upper-shelf role, the value
`restriction associated with that role is prop(cid:173)
`agated to that individual: it becomes a DS3-
`32-SHELF (Figure 4b). If anything about
`Shelf#53 conflicts with this new information,
`an error condition is raised, and Shelf#53 is
`prevented from filling the upper-shelf role.
`
`Explanation, product training, and help(cid:173)
`desk support. CLASSIC can justify all of
`its beliefs.2 Not only can users view any piece
`of information; they can also have any deduc(cid:173)
`tion explained.
`In our first eKample, if the user asks why
`GENERIC2 software became part of the con(cid:173)
`figuration, she learns that adding a DS3-
`SHELF to the lineup caused a rule to fire(cid:173)
`which, in effect, required GENERIC2 soft(cid:173)
`ware. Similarly, the propagation in shown in
`Figure 4 can be supplied if a user wonders
`why Shelf#53 is a DS3-32-SHELF. The
`explanation facility can answer other ques(cid:173)
`tions such as why one object does or does not
`subsume another object, why a rule was
`asserted, or why an error occurred.
`Inferences can also have associated tem(cid:173)
`plates that present explanations in terms that
`are acceptable to the user. For example, in
`some of our systems, we present answers in
`English by associating natural language tem(cid:173)
`plates with explanation options in pop-up
`menus. We could also use forms-based tem(cid:173)
`plates compatible with a help system that
`presents information in a familiar form.
`Explanations and inspection functions let
`product engineers and help-desk personnel
`view product information in one source,
`which could also be made publicly available.
`The ability to justify, explain, and generally
`
`Figure 3. The rule triggering process: (a) individuals lineup#12 and Bay#27 are created to hold the configuration
`state; (b) the upper shelf of Bay#27 is asserted as a DS3-SHELF; (c) the new information about Boy#27's upper shelf
`couses Bay#27 to be reclassified as a BAY-LINEUP-G2; and (d) a rule fires that derives the software requirement for
`lineup#12.
`
`~----------------------------------------------------------------------------------------------------~
`JUlY/AUGUST 1998
`73
`
`FORD 1011
`
`Page 5 of 9
`
`

`
`respond to questions from the sales office
`was very crucial for Prose's success. As a
`help-desk application, the configurator
`becomes the repository for all the product
`information. This encoding can be checked
`for completeness and correctness. Coupled
`with the explanation functions, it can used to
`find why certain information implies or is
`inconsistent with other information. It also
`provides the basis for a more efficient train(cid:173)
`ing environment and a more productive cus-'
`tomer service desk.
`
`Incrementally evolving specifications.
`Description logics let users continually
`refine and change the knowledge base. In
`addition to specifying shelf type or capacity
`information, a user might "instantiate" a
`component description by choosing a par(cid:173)
`ticular part number.
`Because the system must be consistent, the
`interface will only generate choices that
`appear to satisfy all the component con(cid:173)
`straints that CLASSIC derives. To do this,
`we use the component specification as a
`query to the individuals' database. Thus,
`menus are only populated with choices that
`are compatible with known restrictions and
`the options interface is continually adapting
`to new information. The user can also delete
`a system requirement. In this case, any
`deductions resulting from this requirement
`are removed from the specification.
`
`Reasoning for incomplete knowledge.
`Many problems are inherently incomplete(cid:173)
`that is, not all information is known when
`reasoning is required. In configuration exam(cid:173)
`ples, users may state some of the constraints
`on a system and then hope those were enough
`to completely specify a parts list consistent
`with the constraints.
`For example, let us consider the problem
`of buying a cross-connect system. For such
`a system to function, every configuration
`component must be instantiated. If not
`enough information is available to unam(cid:173)
`biguously specify each and every compo(cid:173)
`nent, the configuration is incomplete and can
`cause cost and functioning problems. On the
`other hand, we want our system to infer as
`much as possible about the configuration
`from the information we do have, and we can
`take advantage of this in our applications.
`Suppose the configurator has determined
`that a DACS IV system requires a perfor(cid:173)
`mance-monitoring unit, but as yet has no
`information as to the price range or type. It is
`
`74
`
`Figure 4. Role propagation between individuals: (a) Shelf#53 and Shelf#61 are known instances of 053-SHELF, but
`nothing more specific is known about them; (b) Shelf#53 and Shelf#61 fill the upper-shelf and lower-shelf roles,
`respectively. The knowledge that they must be instances of DS3-32 and DS3-16 is propagated from Bay#27 through
`value restrictions inherited from DS3-BAY.
`
`still possible to deduce something about the
`requirements for such a unit and narrow the
`range of choices. Applications can then
`prompt the user for precise information to
`distinguish between the remaining choices.
`Description logics are good at determin(cid:173)
`ing all the logical consequences of infor(cid:173)
`mation even when that information is in(cid:173)
`complete. They can also help identify the
`knowledge required to complete a specifica(cid:173)
`tion. For example, they can identify the fact
`that two fillers must be specified for a par(cid:173)
`ticular role (like a speaker role) before a con(cid:173)
`figuration is considered complete. Recent
`work on other description logics have for(cid:173)
`malized this notion. 8
`
`Extensible schemas. In our applications,
`users can add new concepts and roles to the
`knowledge base at any time. The telecom(cid:173)
`munications industry, in fact, supports a
`healthy market in third-party circuit-pack
`manufacturing. Thus, if a new object becomes
`available-such as a new type of circuit
`
`pack-a class can be created and can use new
`roles if necessary. Individuals will then be
`classified with respect to the new definition.
`In practice, products are extended and
`updated all the time. Without this practical
`feature, a small change in product knowledge
`requires you to download the entire knowl(cid:173)
`edge base. (AtAT&T, extensible schemas are
`a formal criterion for evaluating software(cid:173)
`application design.)
`
`Inconsistency detection, error handling,
`and retraction. Although our configurator
`application minimizes the opportunity for
`user errors, errors can still occur. Prose does
`not ask CLASSIC to pre-calculate all possi(cid:173)
`ble consequences of a given choice. For
`example, if a shelf or assembly without a slot
`to support auxiliary power is selected for a
`configured system and someone tries to
`include additional main power circuits, a
`conflict will arise.
`Generally, neither CLASSIC nor descrip(cid:173)
`tion logics let the knowledge base maintain
`
`IEEE INTELLIGENT SYSTEMS
`
`FORD 1011
`
`Page 6 of 9
`
`

`
`where different aspects can be emphasized.
`For example, manufacturing has a structural
`product view; sales is more feature- and cost(cid:173)
`oriented. Nonetheless, maintaining a com(cid:173)
`mon product view throughout the process is
`important for the process to function prop(cid:173)
`erly. If everyone operates on common as(cid:173)
`sumptions about product features and func(cid:173)
`tionality, all goes well. If not, the process
`becomes inefficient and unwieldy, with the
`associated cost penalties.
`Maintaining consistency in a complex busi(cid:173)
`ness process is surprisingly difficult. People
`are inventive and quick to implement local
`solutions. When we began working on con(cid:173)
`figurators, many individuals had developed
`legitimate methods of dealing with incorrect
`orders and product configurations. Sometimes
`these methods were as simple as comparing
`an incoming order against handwritten check(cid:173)
`lists. In other cases, people developed entire
`software applications for checking order
`integrity. Given this environment, product
`changes at the design level had to be propa(cid:173)
`gated to each local solution, and then syn(cid:173)
`chronized on a release date. Product knowl(cid:173)
`edge used in different process stages and
`maintained by different people became incon(cid:173)
`sistent over time. These inconsistencies had
`to reported to everyone involved.
`Prose configurators centralized and auto(cid:173)
`mated the manual methods, and replaced
`legacy systems. As a technical solution, Prose
`far surpassed the capabilities of the preexist(cid:173)
`ing legacy systems. This was in large part due
`to CLASSIC's truth-maintenance machinery.
`In the real world, configurator maintenance
`is inherently nonmonotonic. Product updates
`almost always require existing knowledge to
`be modified or removed-such as when
`equipment is discontinued. Replacements
`often have new features that interact with
`existing equipment. Truth maintenance is thus
`a very important asset, particularly for cop(cid:173)
`ing with the conflict detection, consequence
`determination, and explanation required by
`frequent changes and updates.
`
`Knowledge engineering phases. In the
`Prose project, knowledge engineering occurs
`at three levels: modifying an existing product
`knowledge base, adding a new configurator
`to an existing product family, and designing
`a new configurator.
`Maintaining an existing configurator is the
`simplest of the three tasks. Product main(cid:173)
`tainers, rather than programmers, handle the
`vast majority of the error conditions and con-
`
`Figure 5. The Engineer, Furnish, and Install process. Each stage requires product knowledge, but the emphasis con dif(cid:173)
`fer from one stage to another.
`
`an inconsistent state. CLASSIC will roll back
`the knowledge base to the previous consis(cid:173)
`tent state, saving copies of all the individuals
`that led to the error in their inconsistent
`states. If the user asks CLASSIC for an ex(cid:173)
`planation of the error, CLASSIC can access
`the inconsistent state information to gener(cid:173)
`ate an explanation.
`Error handling is the part of a truth main(cid:173)
`tenance system that maintains information
`consistency. It also supports retraction of
`given information and its consequences. For
`example, if a user chooses a system element
`that previously required a particular software
`release or generic, the software is automati(cid:173)
`cally added to the system. If the user later
`decides to retract the element, the software
`would also be removed. This is one way in
`which description logics differ from rule(cid:173)
`based systems; in the latter, rule conse(cid:173)
`quences remain in the knowledge base,
`causing potential conflicts or necessitating
`additional programming support.
`Practically speaking, retraction is a very
`important feature. Configurator users are
`always experimenting with different product
`options and frequently change their mind. In
`our experience, few users will tolerate an
`application that computes all the conse(cid:173)
`quences of input but fails to undo these con(cid:173)
`sequences when the input is retracted.
`Another way that description logics differ
`from rule-based systems is that rule firing is
`not procedural. In rule-based systems, appli(cid:173)
`cations programmers must give some firing
`ordering to rules (by default it is typically
`alphabetical by rule name or chronological
`
`by rule creation), cite rule importance level,
`and assign antecedent group conditions that
`govern firing. A description logic designer
`simply associates a rule with a concept. All
`associated rules fire on any individual that
`becomes an instance of the concept.
`
`Modularity. As long as roles and general
`concepts are defined in advance, two or more
`people can independently design subportions
`of the hierarchy. When the subportions load
`simultaneously, the description logic will
`find any incompatibilities. Also, the concept
`hierarchy can be easily extended with new
`(typically more specific) concepts as the
`knowledge base grows.
`
`Knowledge acquisition and
`maintenance
`
`In our experience, knowledge acquisition
`and maintenance are key to a configuration
`application's success. Although other factors
`are important as well-such as an applica(cid:173)
`tion's ability to deliver optimized, lowest cost
`solutions-the application must offer valid
`and consistent output. Our corporate clients
`were constantly concerned about the consis(cid:173)
`tency and integrity of the product knowledge.
`Hence, over time, that issue acquired more
`and more of our attention.
`
`Maintaining co