RI Revisited:
`Four Years in the Trenches
`
`Judith Bachant
`Intelligent Systems Technology Group
`Digital Equipment Corporation
`Hudson, Massachusetts 01’749
`
`John McDermott
`Department of Computer Science
`Carnegze-Mellon University
`Pittsburgh, Pennsylvania 15213
`
`Abstract
`
`to use a rule-based
`began
`In 1980, Digital Equipment Corporation
`to configure VAX-
`system called Rl by some and XCON by others
`In the
`intervening
`years, Rl’s knowledge has
`11 computer
`systems
`increased substantially
`and its usefulness
`to Digital continues
`to grow.
`This article describes what
`is involved
`in extending Rl’s knowledge base
`and evaluates Rl’s performance during
`the four year period.
`
`198 1 ISSUE of the AI Magazine, an
`IN THE SUMMER
`the formative years” described how a
`article entitled
`“Rl:
`rule-based configurer of computer systems had been devel-
`oped and put to work (McDermott,
`1981). At the time that
`article was written, RI had been used for only a little over
`a year and no one had much perspective on its use or use-
`fulness. RI has now been configuring computer systems for
`over four years. This experience has provided some insight
`into the ease and difficulty of continuing
`to grow an expert
`system in a production environment and into the kind of per-
`formance expectations
`it might be reasonable to have about
`a current generation rule-based system.
`The approach Rl
`takes to the configuration
`
`task and the
`
`roles in Rl’s development.
`A large number of people have played critical
`Among
`those who deserve special mention are John Barnwell, Dick
`Caruso, Ken Gilbert, Keith Jensen, Allan Kent, Dave Kiernan, Arnold
`K&t,
`Dennis O’Connor,
`and Ed Orciuch. We want
`to thank Allen
`Newell, Dennis O’Connor,
`and Ed Orciuch
`for their helpful comments
`on earlier drafts of this article
`
`is represented have been described else-
`way its knowledge
`where (McDermott, 1980) and (McDermott,
`1982). Briefly,
`given a customer’s purchase order, Rl determines what,
`if
`any, substitutions and additions have to be made to the or-
`der to make it consistent, complete, and produce a num-
`ber of diagrams showing the spatial and logical relationships
`among the 50 to 150 components
`that typically constitute a
`system. The program has been used on a regular basis by
`Digital Equipment Corporation’s manufacturing
`organiza-
`tion since January, 1980. Rl has sufficient knowledge of the
`configuration domain and of the peculiarities of the various
`configuration constraints
`that at each step in a configuration
`task it is usually able to recognize just what
`to do; thus it
`ordinarily
`does not need to backtrack when configuring a
`computer system.
`At the beginning of Rl’s development, no clear expecta-
`tions existed about how long it would take to collect enough
`knowledge to make Rl an expert. We did expect that at some
`point
`the rate at which Rl would acquire new knowledge
`that
`if not stop. We even thought
`would at least slow,
`Rl would be done eventually
`(that
`is, Rl would enter a
`maintenance mode of well-defined and minor additions,
`in-
`terspersed with occasional bug fixes.)
`It
`is difficult now
`to believe Rl will ever be done; we expect
`it to continue
`to grow and evolve for as long as there is a configuration
`task.
`It may be that
`if Rl’s domain were less volatile,
`Rl would not require perpetual development.
`But
`it
`is
`
`THE AI MAGAZINE
`
`Fall 1984 21
`
`AI Magazine Volume 5 Number 3 (1984) (© AAAI)
`
`CONFIGIT 1024
`
`1
`
`

`

`NU MBER OF RULES
`3250 -
`
`3000 -
`
`2750 -
`2500 -
`
`2250 -
`
`2000 -
`
`1750 -
`
`1500 -
`
`1250 -
`
`VAX-11/780
`
`(10/79)
`
`VAX-11/725
`PDP-11/44
`PDP-11/24
`MICROVAX-1
`MICRO-PDPl
`
`(11/83
`(11/83:
`(11/83:
`(10/83:
`V/83:
`
`VAX-11/730
`
`(3/82)
`
`I
`l/1/80
`
`I
`l/1/81
`Rl’s Growth
`Figure 1.
`
`I
`l/1/82
`
`I
`l/1/83
`
`I
`1
`./l/84
`
`the
`
`if the domain were less volatile,
`probably also true that
`task would not require a knowledge-based system.
`The early expectations about Rl’s performance were
`likewise vague, except just as Rl was beginning
`to be used,
`a Digital employee responsible
`for the configuration process
`predicted
`that
`for Rl
`to be useful, 90% to 95% of its
`configurations would have to be perfectly correct. This per-
`formance goal is interesting, not so much because RI
`took
`three years to reach it, but because it turned out to be com-
`pletely wrong. Rl’s
`task is just one small part of a process
`designed to ensure that high quality computer systems are
`built. Significant
`redundancy exists in the process precisely
`because historically
`no individual
`has both known enough
`about configuration and been able to pay close enough at-
`tention
`to each order to be entrusted with
`the total respon-
`sibility. Rl was able to provide significant assistance even
`when it knew relatively
`little because the people who used Rl
`did not demand more of it than of its human predecessors.
`The one definite performance expectation almost everyone
`had about Rl
`in its early days was that
`it would always
`configure
`the same set of components
`in the same way.
`It
`is obvious now and should have been obvious then that this
`expectation could have been satisfied only if Rl had been
`discouraged from becoming more expert.
`These expectations about Rl’s developmental and per-
`
`In
`the two parts of the article.
`introduce
`formance histories
`the next section, the focus will be on the kind of involvement
`required
`to extend Rl’s knowledge base. The final section’s
`focus will be on the kinds of erroneous behavior Rl has ex-
`hibited.
`
`Rl’s Developmental History
`
`This section provides a somewhat anecdotal trip through
`Rl’s past. Although
`it mentions the first year, when most of
`the activity was at Carnegie-Mellon University
`the
`[CMU],
`primary
`focus is on the four following years, after Rl began
`to be used at Digital. When CMU handed over the initial
`version of Rl
`to Digital
`in January 1980, Digital scrambled
`to put an organization
`in place that could continue
`its de-
`velopment. This organization, currently known as the Intel-
`ligent Systems Technologies group, began with only five in-
`dividuals, none of whom had any background
`in AI. Over the
`past four years, the group has grown to 77 people responsible
`for eight different knowledge-based systems, one of which is
`Rl. As Rl was developed, an attempt was made to effect
`a division of labor between those people responsible for rep-
`resenting Rl’s knowledge and those responsible
`for collect-
`ing and validating
`that knowledge. Of the initial
`technical
`people, one was an engineer who played the roles of both
`
`22 THE AI MAGAZINE
`
`Fall 1984
`
`2
`
`

`

`to other domain ex-
`a domain expert and of an interface
`perts outside
`the group;
`the other
`three people
`took
`the
`knowledge collected by the engineer and formulated
`it so it
`was compatible with Rl’s other knowledge. When the or-
`ganization was a little over two years old the technical group
`had grown to eight people, five of whom were responsible for
`encoding the knowledge collected and validated by the other
`three. The size of the Rl
`technical group is still about eight.
`Now, however, less of a distinction exists between the people
`responsible for knowledge encoding and those responsible for
`knowledge collection.
`
`The Knowledge Rl Acquired
`
`Over the past four years, the amount of effort devoted
`to adding knowledge to RI has remained relatively constant
`at about
`four worker-years per year. And Rl’s knowledge
`has grown at a relatively constant rate, though the focus has
`shifted around. At times the task of eliminating
`inadequacies
`in Rl’s configuration knowledge has received the most atten-
`tion; at other times, the group’s energies have been directed
`primarily at broadening Rl’s abilities in various ways. Figure
`1 shows the rate at which Rl’s knowledge has grown;
`the
`points in time at which Rl became able to configure new sys-
`tem types are marked. Figure 1 does not show the amount
`of product
`information
`to which Rl has access. This infor-
`mation, which
`is stored
`in a data base, is a critical part
`of the body of information needed to configure a computer
`system correctly. Rl
`retrieves
`the description of each com-
`ponent ordered before it begins configuring a system; while
`configuring
`the system,
`if it determines some piece of re-
`quired functionality
`is missing, it searches the data base for
`components that will provide that functionality.
`Rl currently
`has access to almost 5500 component descriptions. We do
`not have good data on the rate at which the data base has
`grown, but what data we have suggest the growth
`rate is
`quite irregular.
`in number of
`is measured
`In this article, Rl’s growth
`rules. The following values hint at the amount of knowledge
`an Rl
`rule contains. The average conditional part of one
`of Rl’s
`rules has 6.1 elements (the minimum number
`is 1
`and the maximum 17). Each element is a pattern
`that can
`be instantiated by an object defined by as many as 150 at-
`tributes. On the average, a pattern will mention 4.7 of those
`attributes
`(the minimum
`is 1 and the maximum 11) and
`restrict
`the values which will satisfy
`the pattern
`in various
`ways. The tests are mostly simple binary
`functions
`that
`determine whether some value in the object has the specified
`relationship
`to some constant or to some other value in that
`or another object. The action part of an average rule has 2.9
`elements (the minimum
`is 1 and the maximum 10). Each
`element either creates a new object or modifies or deletes
`an existing object. A rule can be applied when all of its
`condition elements are instantiated.’
`
`rules as well as
`the nature of Rl’s
`about
`information
`‘For additional
`those of other systems written
`in 0ps5,
`see (Gupta, 1983)
`
`the first
`Work on RI began in December 1978. During
`four months, most of the effort was on developing an ini-
`tial set of central capabilities. The initial version of Rl was
`implemented
`in OP%, a general-purpose rule-based language
`(Forgy, 1979). By April, Rl had 250 rules. During
`the same
`period, a small amount of effort was devoted to generating
`descriptions of the most common components supported on
`the VAX-111780.
`After
`this demonstration version of Rl had
`been developed, most of the effort during the next six months
`was divided between refining
`those initial capabilities and
`adding component descriptions
`to the data base; in October
`1979, Rl had 750 rules and a data base consisting of 450 com-
`ponent descriptions. During
`the following six months,
`little
`development work was done on Rl either at Digital or CMU
`because the main focus was on defining a career path for Rl
`within Digital. But beginning
`in April 1980, three months
`were spent at CMU in rewriting
`the OPS4 version of RI in
`OPS5 (Forgy, 1981). Given that
`the knowledge was already
`laid out in the OPS4 version, a variety of generalizations
`emerged and the resulting system, though more capable, had
`only 500 rules.
`By the end of 1980, Rl had 850 rules, most of which
`were added by people at CMU to provide Rl with additional
`functionality;
`the primary
`focus at Digital during the second
`half of 1980 was on adding component descriptions
`to the
`data base and providing a group of people with
`the skills
`to take over the continued development of Rl. Most of the
`work on Rl since early in 1981 has been done by people at
`Digital. By March 1981, the group at Digital had extended
`RI so it could configure VAX-11/750
`systems. During
`the
`remainder of 1981, most of the group’s effort was focused
`on refining Rl’s knowledge of how to configure VAX-111780
`and VAX-11/750
`systems.
`In 1982, the focus changed to ex-
`tending Rl
`to cover more systems. While some effort was
`spent in improving Rl’s performance, substantial effort was
`spent in extending
`its scope. By March, a few months be-
`fore the VAX-111730 was announced, Rl was able to configure
`systems, and by July, Rl was able to configure
`VAX-11/730
`systems. At that point, Rl’s knowledge base
`PDP-11/23+
`consisted of about 2000 rules. The remainder of 1982 and the
`first few months of 1983 were devoted primarily
`to refining
`that knowledge. At that point, a concerted effort was made
`to extend Rl’s capabilities so it could configure all the sys-
`tems sold by Digital
`in significant volume. When that
`task
`was finished
`in November 1983, Rl had about 3300 rules
`and its data base contained about 5500 component descrip-
`tions. While a significant amount of time will continue to be
`devoted to extending Rl’s capabilities
`to cover new systems
`as they are announced, effort will also be spent in continuing
`to deepen Rl’s expertise in the configuration domain.
`As Digital has become more dependent on Rl, it has be-
`come increasingly
`important
`that Rl be highly reliable. Thus
`substantial attention has been paid to the question of how to
`combine the demands of reliability with
`those of continuous
`development. Early on, little attention was paid to formaliz-
`ing the developmental process; as problems were reported,
`
`THE AI MAGAZINE
`
`Fall 1984 23
`
`3
`
`

`

`NUMBER
`OF RULES
`
`AVERAGE
`RULES PER
`SUBTASK
`
`AVERAGE
`NUMBER
`OF PARTS
`ORDERED
`
`AVERAGE
`RULE
`FIRINGS
`
`PERCENT OF
`KNOWLEDGE
`FREQUENTLY
`USED
`
`NUMBER
`OF PARTS
`IN THE
`DATABASE
`
`Rl
`
`THE
`
`INITIAL
`
`Rl
`
`THE CURRENT
`VAX-111785
`VAX-11/780
`VAX-111750
`VAX-111730
`VAX-11/725
`MICROVAX-1
`MICRO-PDPll
`PDP-11/23+
`PDP-11/24
`PDP-11/44
`
`777
`
`3303
`2883
`2883
`2801
`2810
`2788
`1516
`1516
`1516
`2786
`2786
`
`76
`
`10 3
`9.8
`98
`97
`97
`97
`73
`73
`73
`9.7
`97
`
`88
`
`78
`163
`171
`111
`85
`34
`34
`44
`49
`43
`43
`
`1056
`
`1064
`2654
`1925
`1300
`1141
`622
`546
`546
`608
`567
`733
`
`44%
`
`47%
`24%
`31%
`29%
`29%
`8%
`18%
`18%
`20%
`13%
`15%
`
`420
`
`5481
`3398
`3398
`2915
`2489
`1981
`1490
`1828
`1894
`1763
`1764
`
`A comparison of the initial and current versions of Rl.
`
`Figure 2.
`
`individuals would collect the needed knowledge, add it to the
`system, and depending on the press of other problems, do
`more or less testing to determine
`that
`the overall capability
`of the system had not worsened. As time passed, the de-
`velopmental process acquired substantially more structure.
`Planned release dates are now preceded by extensive testing
`of the system.
`(McDer-
`the initial version of Rl
`The article describing
`mott, 1982) provides some insight
`into
`the nature of Rl’s
`knowledge by presenting a variety of measurements. Figure
`2 compares the measurements
`from the initial version of Rl
`with corresponding measurements
`from the current version.
`Since a significant amount of the knowledge
`in the current
`version is specific to just a subset of the system types it can
`configure, Figure 2 provides
`the measurements
`for system-
`specific configurers as well as for the union of those config-
`that
`urers. Until
`recently,
`instead of a single version of Rl
`could configure all system types, there was a version of Rl for
`each system type. Each of these versions consisted of a set of
`from 50 to 100 rules specific to a system type and two much
`larger sets of rules; it shared one of these rule sets with all of
`the other system types and the other with
`the system types
`having the same primary bus. About 300 of the shared rules
`were themselves specific to just one of the system types; each
`of these rules was included with
`the shared rules because it
`was relevant to a shared subtask.
`rules are grouped
`together on the basis of the
`Rl’s
`subtask
`to which
`they are relevant;
`the “number of rules”
`column displays
`the total number of rules available
`to Rl
`in performing
`the configuration
`task, and the “average num-
`ber of rules per subtask” column displays the mean number
`of rules in a group. The 3303 rules the current Rl has is
`the union of the rules of each system-specific configurer;
`the
`10.3 rules per subtask is the union of the groups of rules the
`system-specific configurers bring to bear on a particular
`task.
`The “average number of parts ordered” column displays the
`number of components Rl has to configure. This number
`
`24 THE AI MAGAZINE
`
`Fall 1984
`
`listed
`larger than the number of components
`is significantly
`on a purchase order since those line items actually
`refer to
`bundles of configurable components.
`The numbers in the “average rule firings” and “percent
`of knowledge
`frequently used” columns are based on small
`the numbers came from run-
`sets of runs. For the initial Rl,
`ning Rl on 20 typical orders. For the current Rl,
`the num-
`bers came from running each system-specific version of Rl
`on about 20 orders of comparable complexity. The “average
`rule firings” column shows that substantially more is done
`in configuring a VAX-111780 order now than was done ini-
`tially; almost twice as many rules are applied. Two factors
`contribute
`to this increase. The configuration
`task has been
`enlarged by definition
`(i.e.
`there is now more to do), and
`second, there has been an increase in the average number of
`components per order.2
`frequently used” column
`The
`“percent of knowledge
`shows what percentage of the rules are used at least once
`in at least one of the sample runs. Thus for the initial Rl,
`44% of the 777 rules were applied at least once over the 20
`sample runs, and for the current Rl, 47% of the 3303 rules
`were applied at least once over the approximately 200 sample
`runs. The fact that a substantial
`fraction of Rl’s knowledge
`is used only rarely
`is, of course, just what we would expect
`of a knowledge-based system. But
`the percentages for the
`system-specific versions are somewhat misleading. We would
`expect the percentage for each version to be lower than the
`overall percentage because each was run on only about 20
`orders. However, because each version has knowledge
`that
`is not relevant
`to its tasks, the percentages for the versions
`are lower than they otherwise would be. The percentages for
`the VAX-111780,
`the VAX-111750,
`and the VAX-111730 are
`the most accurate, but even they are too low by several per-
`centage points. Since the nature of the knowledge used by
`
`the average, 1.67 VAX-11/780
`20n
`configure an order.
`
`cpu minutes are required
`
`to
`
`4
`
`

`

`the percentage
`that
`it is likely
`each version is quite similar,
`of the knowledge frequently used by each is pretty much the
`same-somewhere
`between 35% and 40% .
`About 65% of the 2526 rules added to Rl since 1980
`extend Rl’s general configuration
`capabilities;
`only about
`35% of the rules are specific to a single system type. Of the
`65% at least 15% were added to correct or refine knowledge of
`how to perform some subtask. This lower bound is suggested
`by the fact that
`the “average number of rules per subtask”
`increased by 30% during
`the past four years (i.e., about 230
`rules were added to the groups of rules applicable
`to the
`subtasks the initial Rl knew how to perform); adding a rule
`to the group applicable
`to some subtask is almost invariably
`done to correct or refine the knowledge of how to perform
`that subtask.
`The 15% is a lower bound because as the
`knowledge required
`to perform some subtask grows, it may
`become evident
`that what was viewed as a single subtask
`can be viewed as two or more simpler subtasks; what we
`do not know is how much the average number of rules per
`subtask would have grown if this subtask splitting had never
`occurred.
`
`The Kinds of Changes Rl Has Undergone
`
`the task of developing Rl had just
`As it turned out,
`begun when it was first put
`into use.
`In this section, we
`attempt
`to give a flavor of the kinds of changes that have
`been made to Rl over the past four years by examining a few
`examples in some detail. Our primary purpose in examining
`the growth of Rl’s knowledge
`is to better understand what
`is involved
`in adding knowledge
`to such a system. We can
`identify
`four reasons why knowledge was added to Rl:
`
`(adding knowledge
`refinements
`l To make minor
`improve Rl’s performance on an existing subtask);
`l To make major
`refinements
`(adding
`the knowledge
`required
`for Rl
`to perform a new subtask);
`l To extend
`the definition of the configuration
`significant ways.
`
`task in
`
`to
`
`is
`Ordinarily when people talk about why knowledge
`added to an expert system, they seem to have the first reason
`in mind. As we have seen, of the more than 2500 rules
`added to Rl during
`the past four years, the data in Figure
`2 suggest that more than 10% have been added to make
`minor refinements,
`fewer than 40% have been added to make
`major refinements, at least 35% have been added to provide
`functionality
`needed to deal with new system
`types, and
`perhaps as many as 15% have been added to extend
`the
`definition of the task in significant ways.
`Minor Refinements. A knowledge addition of the first
`type is required when Rl cannot perform some subtask that
`it was thought
`to be able to perform. For example, over the
`years RI has made several errors
`involving
`the placement
`of backplanes
`in boxes. One instance of such an error has
`to do with a backplane’s
`In one variety
`location.
`of a 24
`slot box, because of power considerations, a backplane
`is
`
`if it covered
`that
`to cover slot 10. Rl knew
`not permitted
`slot 10 when placing
`a backplane,
`it needed
`to move
`that
`backplane toward the back of the box so the backplane’s front
`edge would be in slot 11. Rl’s knowledge was incomplete
`because it did not know it had to move any previously placed
`backplane
`from
`the front of the box toward
`the middle so
`that its back edge would be in slot 9. This backplane has to
`be moved toward
`the middle because leaving a larger space
`between the two backplanes would mean the standard cable
`used to connect backplanes could not be used (since it is not
`long enough). Fixing Rl was a straightforward
`task, but it
`required a certain amount of creativity
`(i.e., it was not just
`a matter of “adding some more domain knowledge.“) What
`lacked was any notion of “deliberately
`vacant space.”
`Rl
`In order to provide rules that could recognize situations
`in
`which blank space was inappropriately
`positioned, Rl had
`to have the concept of blank space and an understanding of
`how to make a note that a particular
`space had been left
`blank on purpose. Given this, it was straightforward
`to add
`a few rules that recognized when some piece of blank space
`was inappropriately
`located and swap it with a backplane.
`Major Refinements. A knowledge addition
`that results
`in a major refinement
`to Rl can be made in two kinds of
`situations: when Rl does not have any knowledge about how
`to perform some subtask, and when its knowledge of how to
`perform some subtask becomes so tangled
`that ways need
`to be found of representing
`the knowledge more generally.
`Brief examples of both situations are presented below; in the
`following section we provide a more lengthy analysis of one
`attempt
`to rewrite a set of rules, initiated almost purely
`to
`increase generality and understandability.
`Most of the modules Rl configures on a UNIBUS
`consist
`of one or more boards that plug into backplanes which go
`in boxes.
`If multiple boards are required,
`they are usually
`placed next to each other in the same backplane. A situation
`unfamiliar
`to Rl arose when a module was designed with
`boards on two buses.
`Its first board was to be configured
`in an SPC backplane while
`the three
`remaining
`boards were
`to be configured
`in a special backplane
`that had to be lo-
`cated in the same box as the first board, but not in the same
`backplane. One way of extending Rl
`to handle
`this new
`component would have been to use a look-ahead strategy;
`Rl would have checked for space, power, and cabling con-
`straints on the special backplane before configuring
`the first
`board. An alternative would have been a simple backtrack-
`ing strategy. The approach Rl actually
`took involved a com-
`bination of both
`look-ahead and backtracking.
`RI applies
`the same rules it uses for other modules
`to configure
`the
`first board; a few special rules then try
`to foresee abstract
`constraint violations
`involving
`the rest of the boards.
`If a
`problem
`is found, the first board is unconfigured.
`If no con-
`straints are violated, power and space are reserved for the
`remaining boards.
`Early in Rl’s history, only two types of panels needed to
`be considered. A few rules were sufficient
`to guard against
`the possibility of trying
`to configure two panels in the same
`
`THE AI MAGAZINE
`
`Fall 1984 25
`
`5
`
`

`

`space in a cabinet. Templates were used to describe panel
`placement possibilities;
`the rules recognized when some par-
`ticular space was already occupied and avoided that space.
`As Digital
`introduced new products
`the situation became
`increasingly complicated until
`five different
`types of panels
`as well as disk drives and boxes could potentially
`occupy
`the same space with differing degrees of overlap. Because
`the original approach
`required all possible conflicts
`to be
`enumerated,
`it became increasingly unwieldy as the prob-
`lem grew in complexity. The new solution
`involved redesign-
`ing the templates so the information
`they contained could
`be manipulated by a small number of more general rules
`and by making minor changes to the action parts of about
`60 already existing rules that dealt with cabinet space deci-
`sions. This strategy worked well for about a year until Digital
`redesigned its cabinets to comply with new FCC regulations.
`At that point, the templates became too unwieldy because of
`the sheer number of possible individual
`locations; since the
`redesign also eliminated most of the irregularities of the pre-
`vious problem,
`it became possible to simplify
`the templates
`and keep track of potential conflicts with a few very general
`rules.
`
`New System Types. Providing Rl with the functionality
`it needed to deal with new system types has constituted a
`significant portion of the development effort. Since major
`configuration differences exist among the various buses sup-
`ported by different CPU types,
`it was not clear
`initially
`how much configuration
`knowledge
`is common across sys-
`tem types. When a VAX-111750
`configurer was developed,
`the VAX-111780
`configurer was used as a model, but
`the
`knowledge bases were initially
`completely separate. Once
`the VAX-111750 configurer had enough knowledge to be use-
`ful, it was merged with
`the VAX-111780 configurer. On the
`other hand, the VAX-II/730
`configurer was integrated,
`from
`the beginning of its development, with the older Rl; the new
`version was developed by creating a small knowledge base
`(consisting of about 100 rules) specific to the VAX-11/730,
`adding some rules specific to the VAX-11/730 to the common
`knowledge base, and generalizing several of the rules in that
`common knowledge base. This approach worked well for the
`VAX-111730, but when we turned our attention
`to the PDP-
`11/23+, we reverted
`to the approach we had used for the
`Several factors were involved
`in this decision.
`VAX-11/750.
`Rl, up to this point, knew only of VAX-11 systems, which
`are UNIBUS and MASSBUS based, while the PDP-11/23+
`is
`based on the LSI22 bus. The rules for configuring
`these buses
`have little
`in common. Moreover,
`the PDP-11/23+ supports
`a variety of operating systems, requires a completely different
`paneling structure, and assumes different power and capacity
`characteristics
`for its boxes and backplanes. Since the PDP-
`11/23+ is quite dissimilar
`to the VAX-11 systems, a separate
`version of Rl was developed for this task. Each of the sub-
`sequent system configurers was integrated with either
`the
`VAX-11 or the PDP-11/23+
`system (depending on whether
`it had a UNIBUS or a LS122 bus). Recently, it was decided
`that in a production environment,
`it would be advantageous
`
`26 THE AI MAGAZINE
`
`Fall 1984
`
`to have one single system; by April 1984, all of the system
`configurers had been merged. Future system type additions
`will be part of this single version of Rl from the beginning
`of their development.
`Adding
`the knowledge required to deal with new system
`types is non-trivial even when the new type is quite similar to
`types Rl already knows how to configure. Part of the effort of
`extending Rl’s configuration capabilities
`to cover a new type
`is due simply
`to the added amount of knowledge. For each
`of the types, we have had to add a great deal of data to the
`data base as well as make extensive rule changes and addi-
`tions. Many of the decisions involve how to represent the new
`knowledge
`in the rules, but new data base representations
`are sometimes also required. The full extent of the effort
`varies, depending on the degree of similarity
`between the
`added system type and the types Rl can already configure.
`When there is a high degree of similarity,
`the form in which
`the existing knowledge
`is represented provides substantial
`guidance for how to represent the new knowledge. When the
`new system is quite dissimilar, substantial amounts of design
`are required.
`role in Digi-
`As Rl’s
`the Task Definition.
`Extending
`tal’s manufacturing process has evolved, knowledge has been
`added to Rl
`that extends
`the definition of its task. For
`example, Rl was extended
`in January of 1983 to handle
`“multiple-CPU”
`orders. Rl was originally designed to deal
`with orders containing a single CPU. But multiple-CPU or-
`ders have become increasingly common, especially with
`the
`advent of smaller system types where multiple
`identical sys-
`tems and/or several different systems on the same order are
`the norm. Part of the challenge of extending
`the definition
`of Rl’s
`task
`involves
`finding a way to realize some new
`capability
`that does not require extensive modifications
`to
`Rl.
`In this case, we avoided the temptation
`of trying
`to
`modify Rl
`to configure multiple,
`loosely coupled systems
`simultaneously.
`Instead, a few new rules (originally about
`10) were written
`to group the components
`into
`individual
`systems; each system was then configured
`in turn. Changes
`had to be made to 5 existing rules that determine what to
`configure and what order information
`to save; a few external
`initialization
`and output
`routines also had to be modified.
`The hard part was determining
`how Rl’s
`task definition
`could be extended most simply.
`it to
`A substantial change to RI in July of 1982 modified
`deal with a different categorization scheme for components.
`The component descriptions had been developed exclusively
`for Rl and were tailored
`to the configuration
`task. As Digital
`developed other knowledge-based systems for other purposes,
`it became desirable
`to have a common data base, where
`the components were categorized
`in a less ad hoc fashion.
`Before Rl could use the new descriptions, nearly all of its
`rules (about 2000 at the time) had to be changed, and for
`several hundred of these rules, the task of reformulation
`took
`considerable
`thought.
`While the difficulty of making changes of any of the four
`types we have just described is highly dependent on the na-
`
`6
`
`

`

`ture and scope of the knowledge that needs to be added, it
`also appears to be dependent on the amount of knowledge the
`system already has. In the early days, when’R1 was small,
`people who joined
`the project were able, reasonably quickly,
`to acquire enough of an understanding of the configuration
`task and of Rl’s approach to it to become competent devel-
`its sheer
`opers. But now that Rl has grown substantially,
`magnitude seems to serve as a barrier to the would-be devel-
`oper.
`It takes much longer now for someone who joins
`the
`group to gain an adequate understanding of how Rl does
`configuration.
`
`A Change over the Years
`
`To provide another view of Rl’s development, we have
`analyzed the changes in Rl’s knowledge
`for two closely re-
`lated tasks. One of the tasks involves deciding what back-
`plane should hold the next set of modules. The other is a
`subtask
`that may or may not be performed depending on
`what the backplane selection possibilities are. The decision
`of what backplane
`to configure next
`is constrained by the
`pinning
`type of the modules, the space and power available
`for them, the current
`length of the bus and its loading, and
`the number and mix of backplanes that have been ordered.
`A good backplane choice is one that minimizes
`the number
`of additional components
`that have to be added, while satis-
`fying all the constraints.
`The subtask
`is performed