A Framework for Model-Based Adaptive Training

Scope: The part of the domain within which training takes place

Defining what is included in a model and what is excluded determines the scope of a model. This property is generally used so that a trainee can learn a bit at a time. In ITSIE, the scope is always determined by the physical extent of an industrial process or product.

In the MOBAT framework a more general definition based on the concept of a problem-space is used to determine the scope with conceptual boundaries. A problem space provides a useful boundary for the scope of an (executable) domain model. Training objectives are associated with training goals which are realised in problem-spaces. For all problem solving, it is important to recognise the goal and a context within which the goal is to be achieved.

A problem space is the arena of problem solving for a set of related tasks with reasoning methods and representation of domain variables. As in ITSIE, the domain variables that determine scope are effectively separated into two classes:

  1. exogenous – external to the problem space set by the environment, and
  2. endogenous – which are completely determined by actions internal to a problem-space.

In ITSIE there are no guidelines on how to set the scope (i.e., define a part) of the domain model. In the MOBAT framework the scope is determined by mapping training objectives into a conceptual problem-space structure. Each problem space can be further specified with a variety of model properties for a principled use of multiple domain models within the training system architecture.

Figure 6-5 Partial Workmanship-MOBAT Problem Space Map

Figure 6-5 Partial Workmanship-MOBAT Problem Space Map

A partial problem space map for Workmanship-MOBAT is shown in Figure 6-5. The scope of Workmanship-MOBAT problem spaces is essentially determined by grouping related tasks. The tasks for each problem space, as in Proto-MOBAT, are derived from task decomposition which leads to the set of generic primitive tasks from the QUIC project.

To create a working system, the gathering and acquisition of appropriate facts and basic information is a required activity. This acquisition of information provides an additional task primitive for the domain model [Sime 1994]. The task primitive to acquire is used to gather the initial set of observations from printed circuit boards and component recognition.

The remaining task primitives are derived from the QUIC task classification. However, the task “to identify” is renamed “to diagnose” in order to avoid confusion between the interpretation and identification tasks. The workmanship expert task primitives are:

  1. to interpret product features; and
  2. to decide product disposition related to optimum, minimum acceptable and unacceptable manufacturing standards.

The manufacturing process defect expert task primitives are:

  1. to diagnose the most likely problem causes; and
  2. to predict short & long term fixes, preventions and corrective action to improve plant operating conditions.

The process expert task primitive is to execute manufacturing process procedures. The screen print simulation is designed to accommodate training tasks for combinations of all of the above task primitives. Alternative or additional screen print process models are possible with qualitative models, but these models are less general.

A total of 19 problem spaces (not shown in Figure 6-5) similar to the screen print process have been specified, each problem space covering a separate area of the manufacturing process for printed circuit board assembly.

In summary, within the MOBAT framework, the scope of a model is represented in problem spaces which is determined by training objectives and task decomposition. Each of the problem space entities are independent models, each covering an aspect of the overall training domain.
Flower Show
© | | Sitemap