Articles
`
`A Knowledge-Based
`Configurator That Supports
`Sales, Engineering,
`and Manufacturing at
`AT&T Network Systems
`
`Jon R. Wright, Elia S. Weixelbaum, Gregg T. Vesonder, Karen E. Brown,
`Stephen R. Palmer, Jay I. Berman, and Harry H. Moore
`
`n PROSE is a knowledge-based configurator platform
`for telecommunications products. Its outstand-
`ing feature is a product knowledge base written
`in C-CLASSIC, a frame-based knowledge representa-
`tion system in the KL-ONE family of languages. It
`is one of the first successful products using a KL-
`ONE–style language. Unlike previous configurator
`applications, the PROSE knowledge base is in a
`purely declarative form that provides developers
`with the ability to add knowledge quickly and
`consistently. The PROSE architecture is general
`and is not tied to any specific telecommunica-
`tions product. As such, it is being reused to
`develop configurators for several different prod-
`ucts. Finally, PROSE not only generates configura-
`tions from just a few high-level parameters, but
`it can also verify configurations produced manu-
`ally by customers, engineers, or salespeople. The
`same product knowledge, encoded in C-CLASSIC,
`supports both the generation and the
`verification of product configurations.
`
`PROSE (product offerings expertise) is a
`
`knowledge-based engineering and order-
`ing platform that supports sales and
`order processing at AT&T Network Systems
`(AT&T-NS). The cornerstone of the PROSE
`architecture is a product knowledge base writ-
`ten in C-CLASSIC, a knowledge representation
`system in the KL-ONE language family that was
`developed at AT&T Bell Laboratories (Borgida
`et al. 1989). Currently, PROSE is being used to
`provide configurations for sales proposals and
`to generate factory orders for manufacturing.
`Some examples of products that are currently
`
`being configured by PROSE are the cross-con-
`nect systems DACS IV-2000 and DACS II CEF
`as well as the remote cell sites for the AT&T
`Autoplex mobile telephone system. We
`expect PROSE to be deployed for highly
`optioned products across all AT&T-NS busi-
`ness units.
`The PROSE platform is closely integrated with
`the corporate infrastructure for ordering prod-
`ucts, and it has communication links to the
`mainframe systems that support order process-
`ing and manufacturing. PROSE can produce a
`detailed materials list and pricing for sales pro-
`posals, it can electronically place orders and
`initiate billing, it can send manufacturing
`specifications to the factory, and it can pro-
`duce instructions for on-site installers. Most
`importantly, the PROSE architecture is general
`and is not tied to any specific product.
`The motivation underlying the PROSE proj-
`ect was to solve what we initially called the
`data-synchronization problem. In a large
`company offering complex products, ordering
`information is typically distributed among a
`variety of sources, both formal and informal.
`The distributed, informal nature of this criti-
`cal information makes it difficult to maintain
`in an up-to-date, valid, and consistent way.
`The official repositories of product informa-
`tion at AT&T-NS are the engineering draw-
`ings. As technical documents, they cannot be
`read and understood by everyone. Conse-
`quently, the ordering information in the engi-
`neering drawings is reworked into paper
`
`Copyright © 1993, AAAI. 0738-4602-1993 / $2.00
`
`FALL 1993 69
`
`AI Magazine Volume 14 Number 3 (1993) (© AAAI)
`
`Page 1 of 12
`
`FORD 1120
`
`

`
`Articles
`
`Our
`experience is
`that within
`the context of
`the PROSE
`application,
`consistency
`checking has
`somewhat the
`feel of
`programming
`in a
`strongly
`typed
`programming
`language,
`where
`inconsistent
`and incorrect
`uses of data
`types are
`caught by the
`compiler.
`
`70 AI MAGAZINE
`
`ordering guides, informal spreadsheet pro-
`grams used by account executives, and vari-
`ous personal computer (PC)–based configura-
`tor programs. The product information
`contained in these sources frequently
`becomes obsolete and out of synch with the
`engineering drawings.
`Inaccurate orders, when combined with
`products that are so highly technical in
`nature, cause delays in order processing and
`manufacturing and can result in billing dis-
`crepancies. PROSE seeks to centralize this infor-
`mation, or product knowledge, in a single
`source, and put it in a form that can be made
`available to anyone who needs it. Having
`every team member working off the same
`page, so to speak, greatly reduces rework in
`the ordering process, improves quality, and
`reduces cost.
`The earliest and best-known configurator
`application that used techniques pioneered in
`the AI community was developed at Digital
`Equipment Corporation in conjunction with
`Carnegie Mellon’s John McDermott (McDer-
`mott 1982; McDermott and Bachant 1984;
`Barker and O’Connor 1989). The research ver-
`sion was called R1 and later become known as
`XCON in its production version. R1 used pro-
`duction rules to represent knowledge about
`configuring Digital’s computer systems.
`Although production rules had advantages
`over the conventional development
`approaches that had been tried at Digital pri-
`or to R1, some drawbacks surfaced after the
`deployment of R1 in 1981. The most serious
`was the effort needed to maintain an up to
`date, consistent, and valid collection of pro-
`duction rules. Digital estimated that 40 to 50
`percent of the R1 product knowledge changes
`each year (Bachant 1988). By some estimates,
`there have been as many as 6000 R1 produc-
`tion rules. The rate of change, coupled with
`the sheer number of rules needed to ade-
`quately represent R1’s product knowledge,
`made R1 software maintenance an expensive
`process. Subsequently, special techniques had
`to be developed to make software mainte-
`nance easier and more cost effective (Bachant
`1988).
`For a configurator application, product-
`ordering conventions serve as software
`requirements. Responding quickly to changes
`in requirements is especially important in
`this application domain because the inability
`to order new product features through a con-
`figurator dramatically affects utility. Develop-
`ment schedules for a configurator tend to be
`driven by the pace of change in the product,
`not by the developer’s sense of what can be
`
`delivered when.
`In addition, it seems to us that the term
`knowledge-acquisition bottleneck is especial-
`ly meaningful for configurator applications.
`The R1 project, partly in response to the fact
`that the Digital product knowledge was too
`complex for one person to maintain, devel-
`oped schemes for factoring rules into mod-
`ules so that the maintainers could specialize
`within the product domain (Bachant 1988).
`Having access to people who understand the
`product is a key element in the success of a
`configurator project.
`Thus, a configurator application such as
`PROSE has three critical problems to address:
`(1) the acquisition of product knowledge, (2)
`rapid and sometimes unexpected changes in
`product knowledge, and (3) the complexity
`of software enhancements and maintenance.
`In part, PROSE responds to these problems
`by taking advantage of knowledge representa-
`tion techniques originally introduced by KL-
`(Brachman and Schmolze 1985).
`ONE
`Although there has been active research on
`KL-ONE–style languages since 1975, and
`research prototypes have demonstrated feasi-
`bility in several cases, heretofore few success-
`ful production software applications have
`used a KL-ONE–style representation (O’Brien,
`Brice, and Hatfield 1989). However, we think
`other successes are likely to follow.
`The use of C–CLASSIc, whose ancestry can be
`traced directly to KL-ONE, provides the PROSE
`platform with several key advantages. With
`some exceptions to be discussed later, prod-
`uct knowledge in PROSE is isolated to a single
`module—the product knowledge base. C-CLAS-
`SIC encourages a reasonable organization for
`the product knowledge and enforces internal
`consistency. Inconsistencies in the knowledge
`base are often flagged in the compilation
`stage and, at other times, are caught during
`testing. Both kinds of inconsistencies are
`identified by C-CLASSIC’s internal integrity-
`checking mechanisms.
`Our experience is that within the context
`of the PROSE application, consistency checking
`has somewhat the feel of programming in a
`strongly typed programming language, where
`inconsistent and incorrect uses of data types
`are caught by the compiler. C-CLASSIC’s consis-
`tency checking has had a beneficial effect on
`both the maintainability of the PROSE product
`knowledge and the quality of the configura-
`tor’s output.
`Like that of its predecessors, the simplicity
`of C-CLASSIC’s description language and the
`tractability of its inference algorithms are
`linked. C-CLASSIC provides only a few primitive
`
`Page 2 of 12
`
`FORD 1120
`
`

`
`operators with which knowledge can be
`described. These operators were chosen at
`least in part to avoid intractability in the
`underlying subsumption algorithm (Levesque
`and Brachman 1987). In particular, the
`description language lacks true disjunction
`and has no way to express negation. Never-
`theless, we have not encountered major prob-
`lems when we encoded the product knowl-
`edge for our AT&T Network Systems products.
`To the contrary, we feel that C-CLASSIC has
`encouraged the encoding of product knowl-
`edge in a natural way. Subject-matter experts
`with a variety of engineering and business
`backgrounds, when provided with a small
`amount of assistance from someone who
`understands C-CLASSIC, have been able to easi-
`ly relate to and understand the product
`knowledge encoded in C-CLASSIC.
`In this context, standard software-engineer-
`ing techniques such as code inspections take
`on a special meaning. Essentially, these ses-
`sions perform double duty as verification
`exercises. Typically, a product expert partici-
`pates and often clarifies misunderstandings in
`the ordering knowledge for a product. In
`most cases, the C-CLASSIC expressions are close
`to the expert’s intuitive understanding of the
`product, providing an uncommonly strong
`basis for communication between the devel-
`oper and the product expert.
`C-CLASSIC’s contribution to the PROSE project
`is unmistakable. Maintenance and customiza-
`tion of a product configurator for specific user
`communities can be accomplished in a clean
`and straightforward way. Reuse of the descrip-
`tive product knowledge is one of PROSE’s most
`interesting features, and it has some genuine
`benefits. In particular, the sticky problems
`associated with updating, synchronizing, and
`distributing product knowledge to the appro-
`priate people are much easier to control in
`the PROSE environment.
`
`The PROSE Application
`The PROSE platform is geared toward configur-
`ing telephone switching and transmission
`equipment. By their nature, these products
`are complex and have many optional fea-
`tures. Although there is a trend toward scal-
`ing down the number of available options for
`individual products, customers like the ability
`to customize products to their specific needs.
`To provide a concrete example of the capabili-
`ties of the platform, we briefly describe the
`DACS IV-2000 cross-connect, which was the
`first product to be made available within the
`PROSE platform.
`
`DACS IV-2000 is a digital cross-connect sys-
`tem that processes digitized signals at a DS1
`or DS3 rate.1 A complete lineup consists of
`nine 7-foot frames (called bays when they are
`equipped and working) connected by cabling.
`The positions in the lineup are significant and
`are numbered from left to right. Each bay
`contains as many as four shelves or modules
`of electronic gear. A 6-bay DACS IV-2000 con-
`figuration is shown in figure 1.
`There are 13 types of DACS IV-2000 bay, 3
`of which appear in figure 1. The modules
`within a bay can be equipped with different
`kinds of circuit packs depending on what
`capabilities are desired. In addition, compati-
`ble cabling and software must be ordered.
`Although we have not tried to produce an
`exact calculation, the number of possible con-
`figurations is large, perhaps exceeding
`100,000 or more. The cost of a complete nine-
`bay lineup, including spare circuit packs, can
`easily extend into seven figures.
`The time needed to process orders prior to
`manufacturing is called the up-front order
`interval. The rework and delay associated with
`the processing of invalid configurations dur-
`ing the order interval is a significant contribu-
`tor to the cost of providing a new DACS IV-
`2000. Significant benefits are associated with
`reducing the length of the order interval, not
`the least of which is increased customer satis-
`faction. For DACS IV-2000 prior to PROSE, the
`time period for getting manually produced
`equipment specifications to the factory was
`generally 7 to 14 days. PROSE is capable of
`delivering valid orders to the factory at the
`push of a button.
`Central to the PROSE application, no matter
`what aspect is being discussed, is the materials
`list, which is a description of the materials
`needed to assemble and install a configura-
`tion. It is used for producing a bill of materi-
`als for the shop floor, billing and shipping to
`customers, generating instructions to
`installers, and communicating with cus-
`tomers about the product. In essence, the
`materials list serves as a manufacturing speci-
`fication, telling the factory what to assemble.
`For a nine-bay lineup, there would be sepa-
`rate materials lists for each of the bays plus
`separate lists for DACS IV-2000 software and
`cabling. A completed order also includes
`installation instructions (where to locate and
`how to wire each bay). PROSE generates all the
`information that is associated with manufac-
`turing and installing the equipment it
`configures.
`PROSE has three interfaces that support dif-
`ferent aspects of sales, engineering, and man-
`
`Articles
`
`… the sticky
`problems
`associated
`with
`updating,
`synchroniz-
`ing, and
`distributing
`product
`knowledge
`to the
`appropriate
`people are
`much easier
`to control in
`the PROSE
`environment.
`
`FALL 1993 71
`
`Page 3 of 12
`
`FORD 1120
`
`

`
`Articles
`
`72 AI MAGAZINE
`
`Blank
`Panel
`
`DS3
`Interface-32
`Module
`
`DS3
`Interface-32
`Module
`
`Blank
`Panel
`
`DS1
`Interface
`Module
`
`DS1
`Interface
`Module
`
`DS1
`Interface
`Module
`
`DS1-P
`Interface
`Module
`
`DS1
`Interface
`Module
`
`DS1
`Interface
`Module
`
`DS1
`Interface
`Module
`
`DS1-P
`Interface
`Module
`
`Fuse and Alarm
`Panel
`
`Switching
`Power
`Module
`Auxiliary Power
`Module
`
`Memory
`Controller
`Module
`
`Switching
`Module
`
`Fan Assembly
`
`DS1
`Interface
`Module
`
`DS1-P
`Interface
`Module
`
`DS3
`Interface-
`32
`Module
`
`Blank
`Panel
`
`DS3
`Interface-32
`Module
`
`DS3
`Interface-32
`Module
`
`DS3
`Interface-16
`Module
`
`Blank
`Panel
`
`Bay
`Position 2
`
`Bay
`Position 3
`
`Bay
`Position 4
`
`Bay
`Position 5
`
`Bay
`Position 6
`
`Bay
`Position 7
`
`Figure 1. A 6-Bay dacs iv-2000 Configuration.
`
`ufacturing. Distinct user communities are
`served by the three interfaces, but all three
`draw on the same product knowledge base.
`Having a single-product knowledge base
`allows PROSE to avoid problems associated
`with synchronizing knowledge and data or
`resolving conflicts in several software applica-
`tions.
`The FPQ (firm price quote), or pricing,
`interface: Because accurate price quotes are
`not possible without knowing all the equip-
`ment needed by an application, sales teams
`have technical consultants with the responsi-
`bility of producing price quotes with itemized
`lists of equipment and prices. From a few
`high-level parameters, FPQ can produce a price
`quote for a complete nine-bay DACS IV-2000
`lineup, including compatible software releas-
`es and cabling, in a few minutes. FPQ output
`is such that it could be turned into a valid
`order and sent directly to the factory.2 Fre-
`quently, technical consultants use FPQ to
`explore what-if scenarios to help the cus-
`tomer find the right configuration.
`The SPEC (specification), or engineering,
`interface: SPEC is intended for AT&T engi-
`neers who might be working either on inter-
`nal AT&T applications or as consultants to
`outside customers. SPEC requires more input
`from the user than the FPQ interface, but it is
`also more flexible. Engineers have the choice
`
`of keying in capacity parameters and feature
`choices, or they can specify the quantity and
`the type of circuit pack for each bay. Like FPQ,
`SPEC output is in the form of an order that can
`be sent directly to the factory’s ordering and
`billing systems.
`The TCE (telephone company engi-
`neered), or customer-service, interface:
`Customers sometimes configure products on
`their own without going through either FPQ
`or SPEC. In such cases, the customer submits
`what is essentially a proposed materials list.
`Because invalid configurations cannot be
`assembled, it is essential to know if the list
`represents a valid configuration. The TCE
`interface allows a customer service clerk to
`key in the materials one item at a time. PROSE
`validates the configuration and formats it so
`that it can be entered in the appropriate
`order-processing systems.
`In addition to serving a diverse community
`of users, PROSE must deal with products that
`constantly change in response to the market-
`place. Although we have observed variations,
`the rate of change for certain products
`approaches that reported by R1-XCON (40 to
`50 percent a year).
`For knowledge engineers, however, the real
`problem is that the scheduling and timing of
`changes is not within their control. The
`inability to produce valid orders for new
`
`Page 4 of 12
`
`FORD 1120
`
`

`
`products and enhancements to existing prod-
`ucts is problematic for any manufacturing
`entity. To really be useful, configurators must
`change in lockstep with new product offer-
`ings. Although the solutions to these prob-
`lems are partly methodological (for example,
`early notification of changes from the design
`community), the use of C-CLASSIC has played
`an important role in our ability to respond
`rapidly with quality results.
`
`C-CLASSIC
`C-CLASSIC (Weixelbaum 1991) is a frame-based
`knowledge representation system derived
`from the KL-ONE family of languages (Brach-
`man and Schmolze 1985; Brachman, Fikes,
`and Levesque 1983; Patel-Schneider 1984;
`Woods and Schmolze 1993). It is a direct
`descendant of CLASSIC (Borgida et al. 1989),
`which was written in Common Lisp and had
`the benefit of years of research on semantic
`nets and frame systems.3 Because of the
`declarative nature of the information encod-
`ed in a C-CLASSIC knowledge base, it and other
`similar languages are sometimes referred to as
`description logics.
`C-CLASSIC inherits its two most salient fea-
`tures from CLASSIC: a simple description lan-
`guage and tractable inference algorithms
`(Borgida et al. 1989). C-CLASSIC is an interpret-
`ed language written in C and portable to any
`UNIX system. C-CLASSIC provides three basic
`types of objects: (1) concepts (or frames),
`which are assertions or descriptions about the
`state of the world; (2) individuals, which are
`particular instantiations of concepts; and (3)
`roles, which provide a way to relate individu-
`als.
`C-CLASSIC provides a simple rule-firing
`mechanism. A rule consists of a left-hand side
`and a right-hand side. The left-hand side is a
`concept, and the right-hand side can either
`be a concept or a function that returns a con-
`cept when called on an individual. Whenever
`an individual is classified under a concept, all
`rules that have this concept as the left-hand
`side fire on the individual, adding the right-
`hand side concept or the result of the func-
`tion call onto the individual’s descriptor.
`Concepts are built up through composition
`of components that primarily include previ-
`ously defined concepts and various types of
`role restrictions. In addition, a controlled
`escape mechanism to the C language is pro-
`vided through test functions and computed
`rules. Test functions are used to test if an indi-
`vidual satisfies criteria that are otherwise
`inexpressible in C-CLASSIC. Computed rules are
`
`Articles
`
`<concept> ::=
`
`<concept-name> |
`(at-least <integer> <role>) |
`(at-most <integer> <role>) |
`(between <integer> <integer> <role>) |
`(exactly <integer> <role>) |
`(all <role> <concept>) |
`(fills <role> [<individual> ...]) |
`(one-of [ <individual> ...]) |
`(range <number> <number>) |
`(lower-limit <number>) |
`(upper-limit <number>) |
`(test-c <function> [ <c-classic-object> ...]) |
`(test-h <function> [ <c-classic-object> ...]) |
`(and [ <concept> ...])
`
`<rule-concept> ::=
`
`<concept> |
`(computed-concept <function> [<c-classic object> . . .]) |
`(computed-fillers <function> <role> [<c-classic object> ...])
`
`<individual> ::=
`
`<host-individual> | <classic-individual>
`
`<host-individual> ::=
`
`<integer> | <float> | <string>
`
`<classic-individual> ::=
`
`<symbol>
`
`<concept-name> ::=
`
`<role> ::=
`
`<symbol>
`
`<symbol>
`
`Figure 2. C-CLASSIC Description-Language Syntax.
`
`used to compute the right-hand side of rules
`that are otherwise inexpressible in C-CLASSIC.
`Figure 2 shows C-CLASSIC’s description-lan-
`guage syntax, and figure 3 shows how to
`define C-CLASSIC objects.
`C-CLASSIC provides the following types of
`inference: (1) automatic classification of new
`concepts and individuals into an existing
`knowledge base; (2) completion or propaga-
`tion of logical consequences, including but
`not limited to inheritance; (3) contradiction
`detection; (4) simple forward-chaining rules
`(or triggers); and (5) dependency mainte-
`nance (for retraction and error recovery).
`All these inference mechanisms are used in
`PROSE. Classification and inheritance are used
`to organize the knowledge base into under-
`standable pieces. In addition, an important
`side-effect of C-CLASSIC’s ability to classify and
`propagate logical consequences is that inter-
`nal consistency is maintained within the
`knowledge base. Sometimes a user can request
`a combination of features that does not repre-
`sent a legal configuration. Contradiction
`detection is used to detect such errors. Next,
`as we discuss in the subsequent section, rules
`are needed to represent the product knowl-
`edge adequately. Finally, users might some-
`times change their minds in the middle of a
`PROSE session. Dependency maintenance gives
`them the opportunity to retract an action
`
`FALL 1993 73
`
`Page 5 of 12
`
`FORD 1120
`
`

`
`Articles
`
`(define-concept <concept-name> <concept> )
`(define-primitive <concept-name> <concept> )
`(define-disjoint-primitive <concept-name> <concept> <partition-index> )
`
`define-concept defines an equivalence between <concept-name> and <concept>. define-
`primitive and define-disjoint-primitive define <concept> as a necessary (but not sufficient)
`condition for <concept-name>. <partition-index> is used for forcing disjointness among con-
`cepts defined with the same defining concept.
`
`(define-individual <classic-individual> [ <concept> ])
`
`Host individuals (numbers and strings) are implicitly defined by the system. define-individual
`defines a CLASSIC individual as an instance of <concept>, which defaults to classic-thing, the
`ancestor of all CLASSIC concepts.
`
`(define-role <role>)
`(define-attribute <role>)
`
`define-attribute implicitly forces all individuals that reference <role> to have exactly one filler.
`
`(define-rule <rule> <named-concept> <rule-concept)
`
`Figure 3. C-CLASSIC Object-Defining Functions.
`
`without losing previously asserted facts or
`inferences.
`At any given time, the collection of objects
`that has been described to C-CLASSIC is
`connected in a network called a classification
`graph. When an object is defined or modified,
`C-CLASSIC searches the classification graph to
`find a location for inserting or relocating the
`object. Changes in the graph might cause
`objects already in the graph to be reclassified,
`or they might cause one or more rules to be
`fired.
`During classification of a new object, a
`contradiction between this object and the
`existing classification graph might be discov-
`ered, or a propagation might result in a con-
`tradiction. To help the user recover from such
`error conditions, C-CLASSIC has standardized
`error-handling and error-reporting capabili-
`ties. Error recovery is facilitated by storing
`dependency information in the classification
`graph. By including information that
`indicates exactly how an individual attained
`each portion of its structure, error recovery
`can be done in a timely fashion. Using the
`dependency information, C-CLASSIC also per-
`mits users to retract previously asserted facts.
`In addition to the C-CLASSIC interpreter, the
`system includes a library of C-CLASSIC func-
`tions that can be called from C. With this
`library, a customized interface was developed
`for PROSE. The system provides error data
`through the C interface, enabling PROSE to
`have its own customized error-handling pro-
`cedures.
`
`74 AI MAGAZINE
`
`PROSE Knowledge Base
`Organization
`Engineering documents that describe each
`product, including comprehensive informa-
`tion on the product’s acceptable configura-
`tions, are the official source of product infor-
`mation at AT&T. For example, the DACS
`IV-2000 knowledge base represents a section
`of the engineering drawings called Table A,
`which describes all the pieces of equipment
`that can be ordered for a product, the time at
`which each item can be ordered, and the pro-
`cedure for determining the desired quantity
`of each item. Product experts often write con-
`cise summaries of the information in Table A
`using their own notation. The summaries
`contain descriptions of simple constraints,
`called compatibility rules by our experts, and
`we have adopted this terminology.
`Compatibility rules are generally derived
`from the physical structure of the product.
`However, other factors are sometimes
`involved, and in general, it is not possible to
`derive all compatibility rules by simply know-
`ing the structure of the product. For example,
`some compatibility rules represent artificial
`constraints imposed by marketing, others
`represent an attempt to make the product
`easier to order, and still others represent con-
`straints required for cost-effective manufac-
`turing.
`Figure 4 shows several compatibility rules
`and their C-CLASSIC representations. The two
`rules are associated with a type of DACS IV
`shelf called a DS1 IF shelf. The description
`that corresponds to a DS1 IF shelf is named
`DS1_IF in the C-CLASSIC knowledge base.
`For the purposes of ordering a product, a
`DACS IV-2000 shelf has 6 attributes: signal
`capacities for ds1 and ds3 signals (ds1_lines
`and ds3_lines); the quantities of ds1 and ds3
`circuit packs needed to satisfy a given signal
`capacity (ds1_packs and ds3_packs); the
`quantity of so-called common circuit packs (a
`general term used for a bundle of power and
`interfacing circuit packs); and pmgr-type (per-
`formance-monitoring generator and receiver)
`circuit packs, which are used to monitor the
`ds1 and ds3 signals. The value restrictions
`(for example, “(range 0 224)”) on DS1_IF in
`figure 4 represent the legal ranges of these
`attributes for a DSF IF shelf.
`Because the pmgr packs and the ds1 packs
`are inserted in the same slots on a DSF IF
`(seven slots available in all), the rule
`DS1_IF_max_ds1_packs limits the legal range
`of ds1_packs with the simple formula
`ds1_packs <= 7 - pmgr using a computed rule.
`
`Page 6 of 12
`
`FORD 1120
`
`

`
`Articles
`
`(define-primitive DS1_IF
` (and
` shelf
` (all ds1_lines (range 0 224))
` (all ds1_packs (range 0 7))
` (all common_packs (range 0 1))
` (all pmgr (range 0 7))
` (all ds3_lines (range 0 0))
` (all ds3_packs (range 0 0))
` )
`
`) (
`
`define-rule DS1_IF_max_ds1_packs
` (and
` DS1_IF
` (test-c fills? pmgr)
` )
` (computed-concept Calc (ds1_packs <= 7 - pmgr))
` )
`
`(set-descriptor DS1IF_max_ds1_packs
` "There are seven slots in a DS1IF shelf for both pmgrs and DS1 packs")
`
`(define-rule DS1IF_eq_ds1_packs
` (and
` DS1_IF
` (test-c fills? ds1_lines common_packs)
` )
` (computed-concept Calc (ds1_packs = (ds1_lines / 28) - common_packs))
`
`) (
`
`set-descriptor DS1IF_eq_ds1_packs
` "Formula for computing ds1_packs from ds1_capacity and common_packs")
`
`Figure 4. DACS IV-2000 Knowledge for a DSF IF Shelf.
`
`tions might exist, we are convinced that rep-
`resenting compatibility rules directly in C-
`CLASSIC is currently the only realistic choice. C-
`CLASSIC makes it possible to represent these
`rules in a rather straightforward way so that
`any time a rule must be changed, only a local-
`ized piece of code is affected. We find the
`expressiveness of the C-CLASSIC description
`language, when enhanced with a few hand-
`coded test functions, to be completely ade-
`quate for our purposes.
`Each product knowledge base in the PROSE
`platform is not simply an undifferentiated
`collection of compatibility rules. Rather, there
`is a standard way in which such rules are
`organized within a product knowledge base
`for all products. We refer to the C-CLASSIC
`structure that describes such an organization
`as the order template.
`The order template describes the items and
`the logic for assembling a valid order. It is the
`organizing principle lying behind each
`knowledge base. Although it differs in certain
`details from product to product, the general
`outline of the order template is the same for
`all products.
`C-CLASSIC provides an important benefit that
`we have not yet discussed. Because all objects
`
`FALL 1993 75
`
`Calc is a general routine that accepts an alge-
`braic expression and returns a C-CLASSIC con-
`cept. In the case where pmgr is filled with the
`integer 2, Calc returns the concept expression
`(all ds1_packs (upper-limit 5)).
`The expression (test-c fills? pmgr) is a filter
`or guard that is used to determine when an
`individual has enough information for com-
`puted-concept Calc to be applied.
`The set-descriptor function immediately
`below DS1_IF_max_ds1_packs simply attaches
`a string to the rule that elaborates what the
`rule means. We anticipate that description
`strings will eventually be used to enhance
`error-handling capabilities or the ability of
`PROSE to explain what it is doing in the con-
`text of the application (the Common Lisp
`version of CLASSIC already has a rudimentary
`way to explain what it is doing). For now, the
`explanations are simple English elaborations
`of what the rules mean.
`The rule DS1_IF_eq_ds1_packs describes
`how to obtain a value for ds1_packs when the
`ds1 capacity of a DS1 IF shelf is known.
`For a new configuration, information about
`the user’s selection of features is passed to the
`knowledge base by filling roles or adding val-
`ue or number restrictions to individuals. As
`information is added, these individuals are
`classified under the DACS IV-2000 concepts,
`triggering computed rules and causing the
`appropriate integrity checks to be performed.
`The rules sometimes cause propagations and
`chaining such that additional integrity checks
`are performed, and additional rules are
`applied.
`It is possible for a configuration to be over-
`constrained. From the user’s point of view, a
`configuration becomes overconstrained when
`an incompatible set of features is selected.
`Perhaps the user wants to have both feature x
`and feature y, but feature x and y, when com-
`bined, exceed some capacity limitation of the
`equipment. In such cases, PROSE provides cus-
`tomized error messages based on the C-CLASSIC
`error-handling features. These messages
`describe the problem adequately, but PROSE
`lets the user decide what feature (or con-
`straint) to change or withdraw.
`The compatibility rule idea is rather deeply
`imbedded in the existing process and the
`thinking of the product experts. For example,
`paper documents describe the compatibility
`rules for each product. These documents are
`used to support manual validation procedures
`for incoming orders at the factory.
`Consequently, product experts are most
`comfortable thinking in terms of compatibili-
`ty rules. Although more satisfying representa-
`
`Page 7 of 12
`
`FORD 1120
`
`

`
`Articles
`
`PROSE SYSTEM
`FPQ
`Interface
`
`TCE
`Interface
`
`SPEC
`Interface
`
`Application Drivers and Report Generators
`
`Data Manager
`
`DACS IV
`2000
`KB
`
`Report
`Data
`
`Orders
`and
`Quote
`s
`
`Operations,
`Administration,
`and Maintenance
`Tools
`
`Factory
`Systems
`
`Access
`Mgr
`
`Customer
`Service
`Systems
`
`Contracts
`and
`Prices
`
`Figure 5. PROSE Software Architecture.
`
`are classified in the C-CLASSIC system, the
`description of each object must, in a sense, be
`consistent with all other object descriptions.
`Inconsistent descriptions are detected at com-
`pilation time, that is, when the knowledge
`base is loaded into C-CLASSIC. In the context of
`the PROSE platform, the inconsistencies repre-
`sent either incorrect knowledge or incorrectly
`encoded knowledge, and they must be inves-
`tigated and corrected. The detection of incon-
`sistencies by C-CLASSIC has been an important
`debugging tool within the PROSE platform.
`
`PROSE Architecture
`Three PROSE installations are currently up and
`working. All are based on the SUN 490 plat-
`form. The first, which processes orders for
`transmission products, is located at AT&T’s
`Merrimack Valley Works Data Center in Mas-
`sachusetts. The second, used for Autoplex, is
`at AT&T Bell Laboratories in Whippany, New
`Jersey, and the third, a microelectronics sys-
`tem, i