A Framework for Model-Based Adaptive Training

Foundation - Role Limiting Methods

For more than a decade, Digital Equipment Corporation has used a system called R1 (or sometimes XCON) to configure the computer systems it manufactures. For R1 and perhaps many other large expert systems, knowledge-base maintenance is made easier if the role that a new piece of knowledge plays can be identified [van de Brug, Bachant & McDermott 1985].

In the main R1 problem spaces there are six roles for knowledge to play: propose-operator, reject-operator, evaluate-operator, apply-operator, recognise-success, and recognise-failure. As similar knowledge roles are used in MOBAT’s design specification methods a discussion of each of these roles is appropriate.

  • Propose-operator knowledge suggests what operators might solve the problem at hand under the current set of circumstances; it is also knowledge of the relative static desirability of those operators. For example three operators that might be proposed in the R1 configure-unibus problem space are the configure-module, the configure-backplane, and the configure-bus-repeater operators. The configure-module and configure-backplane operators, if applicable, are always to be preferred to the configure-bus-repeater operator. The choice between configure-module and configure-backplane is dictated by a variety of situational cues.

  • Reject-operator knowledge is used to reject inapplicable operators proposed by propose-operator knowledge. For example, the configure-module operator might be rejected because of insufficient power of a particular type. The principal reason for separating propose-type knowledge from reject-type knowledge is to allow additional information to become available (the reasons why certain operators are rejected) which in turn can make it possible to select a more appropriate operator.

  • Evaluate-operator knowledge is used to tailor one of the proposed operators on the basis of whatever domain-specific considerations are relevant. A piece of knowledge favours one proposed operator over another under some specific set of circumstances. For example, the configure-module operator would be preferred to the configure-backplane operator if the pinning type of the next module to be configured is the same as the pinning type of the next available slot in the backplane being filled.

  • Apply-operator knowledge defines the actions that are to be performed when some operator is applied. For example, when the configure-module operator is applied, the boards comprising the module must be associated with particular slots in the backplane.

  • Recognise-success knowledge indicates how to determine when a subtask has been satisfactorily completed. For example, if all modules have been configured then there is nothing more to do in the configuration-module problem-space.

  • Recognise-failure knowledge indicates how to determine when the current approach to performing a subtask is not going to succeed. For example, no space remaining in the backplane currently being filled indicates that more space must be identified before the task can be finished.

Control knowledge comes in several varieties and distinguishing among the varieties can substantially enhance the maintainability of a program [McDermott 1988]. RIME is a knowledge engineering methodology devised to help make the on-going development of knowledge-based systems less difficult [Bachant & Soloway 1989, van de Brug et al. 1986].

RIME provides a variety of conceptual structures for imposing coherence on an application program. It encourages the developer to decompose the task (i.e., define subtasks) on the basis of the methods that will be employed in solving the problem. Can RIME’s approach to problem decomposition be used to provide clear problem solving methods for training agents; along with their specification, role and applicability? The definition of problem solving methods is discussed further in the next section.

Flower Show
© | | Sitemap