A Framework for Model-Based Adaptive Training

Domain Expert Realisation

The specification of required training units leads to the development of the domain expert within the training system architecture (see Figure 1-1). Expert systems can be described at 2 levels: the knowledge level and symbol level [Newell 1981]. These terms are due to Allen Newell though there are diverging interpretations of these terms within the AI field. In the MOBAT specification framework, the knowledge level can be viewed as an abstract representation of the domain which links to detail in the symbol level. In Proto-MOBAT the knowledge level is specified using problem spaces with tasks, methods and types of models. Primary information for the knowledge level is obtained from the training unit specification which dictates the required problem spaces with associated tasks to be taught and the type of domain model (procedural, associative or principled).

Both ITSIE and MOBIT projects view the three types of knowledge models (procedural, associative and principled) in terms of increasing abstraction in reasoning about the physical world. Knowledge is viewed as being very specific (fixed) for a procedural model, as situation-dependent observation Þ conclusion pairs in an associative model and as fundamental laws underlying the operation of a physical device with a principled model. Just as the knowledge base for R1 (see Section 2.5.4) did not provide a vocabulary to describe the various roles knowledge will play, so do the three types of knowledge models provide no further guidelines about what kind of organisation can be imposed on its knowledge. As shown by RIME and R1-SOAR (see Section 2.5.5 and 2.6.1), the recognition of a variety of conceptual structures provides coherence on a complex (industrial) knowledge base and substantially enhances the development and maintainability of a model. In Proto-MOBAT the three types of knowledge models are further identified in terms of problem solving methods for doing a task. For an associative model, as demonstrated with the RIME methodology [van de Brug, Bachant & McDermott 1986], an explicit range of methods may be appropriate. For a principled model, as shown in SOAR [Laird et al. 1987], the methods to do a task here are generally weak methods such as generate and test, hill climbing and depth-first search. There is only one specified way to do a task with a procedural model. The way a task can be done, called the (problem solving) method, is a slot in a training unit which is filled in by the domain expert. The trainer agent may wish to select an appropriate method in order to teach different problem solving methods. In all three types of knowledge models, Proto-MOBAT defines the arena for model realisation to be a problem space (and sub-problem spaces).

Expert Specification Levels

Figure 4-6 Expert Specification Levels

A problem space (as in RIME and R1-SOAR) implements a set of related domain specific tasks. The Proto-MOBAT tasks to be realised are available from the training units in the training system design specification. The problem solving methods are the ways to accomplish the task. It is not a single action, but a set of actions (i.e., problem solving steps) organised in a structure. This structure may be shown in an activity diagram or flow chart. For each task, a problem solving method needs to be identified. Methods can be defined which are efficiently applied to a fairly broad set of tasks or each task may have its own domain specific method. The Proto-MOBAT task (Diagnose ( Circuit Board )) has been implemented with the propose-evaluate-apply method and its matching knowledge roles as described in Section 2.5. The sample training unit for this task ( Table 4-2 TU24) has rule-based goal expertise and a preferred rote learning mode. This indicates an associative domain model.

The internal model of the training environment may be either a domain model or case model. A domain model is a set of objects that represent the training domain. A case model is a particular situation being reasoned about, so this is a set of objects which is an example of the domain in a manageable size. For the power plant problem space, a complete domain model comprising all of the power plant physical components is specified. The circuit board problem space is represented using case models, as there can be different components implementing the same logic functionality and different circuit board debug problems are more easily represented as separate examples (i.e., examples focused on specific circuit board problems).

The Proto-MOBAT application is a model-based ITS which requires an explicit domain expert model of the physical device, product or process on which the training task is to be performed. With the addition of a simulation model, this promotes the learning of unforeseen and therefore unspecified situations. Having a simulation model allows the system to be much more general in that the specified expertise can be demonstrated and validated with respect to the simulation model rather than on pre-specified domain expertise models. In Proto-MOBAT the simulation model is combined with an expert domain model with realisation of demonstration training units ( Table 4-2 TU3, TU9, TU23). In this research, simulation models are quantitative representations of physical systems in the training domain. Association models and procedural models are qualitative (i.e., knowledge-based) representations of domain expertise.

The knowledge level is important because it identifies the properties of the knowledge to be captured rather than the way in which it is held in a computer program. The symbol level is the implemented knowledge representation. The symbol level can be created with either general purpose programming languages, or specialised expert system tools for principled, associative or procedural models. Using a programming language that closely reflects the properties specified at the knowledge level has the advantage that the transformation is not too large but computational efficiency may be reduced. A general software architecture such as SOAR contains the necessary mechanisms for realising all three model types. Within the MOBIT project, a tool set approach has been adopted supporting different programming languages for each type of model [MOBIT 1994, W2 & W7].

Flower Show
© | | Sitemap