A Framework for Model-Based Adaptive Training

What are the Tasks a Trainee is Expected to Learn?

Task decomposition reduces training objectives into primitives which can then be associated with the available training material. The initial task decomposition is not so much part of the executable training system as a pre-requisite for the training system design specification. However, during system realisation this task specification is used to link to detail at the symbol level. In the MOBAT framework, the tasks a successful trainee is expected to learn (to perform) are:

  1. coupled to concepts from previous training subject analysis;
  2. translating training objectives into specific measurable goals;
  3. smaller in scope than objectives;
  4. instances of expected trainee performance that can be reliably observed and assessed as outcomes of training; and
  5. it is essential that tasks are clearly and unambiguously stated.

Task decomposition is the process of taking the training objective and decomposing it into a finite set of primitive tasks that can be recognised by the training agents. As the subject domain in industrial training is not always a well-defined physical system, an extension is presented for the QUIC task decomposition based on reasoning tasks about the present, past or future behaviour of the training domain. To achieve a specific training objective for a physical system, Figure 2-1 QUIC Generic Task Classification [Leitch & Gallanti 1992] shows the five primitive tasks that a trainee may have to do. In order to capture domain information, in her thesis, Julie-Ann Sime argued for the addition of a sixth task called acquisition [Sime 1994]. For the MOBAT specification experiments this task has been found useful to capture training situations and information needed by the training agents. All 6 tasks have been adapted for the MOBAT specification framework. The type of information these tasks operate on in the MOBAT specification framework is described below.

  • To Acquire: This task represents the capture of the training situation in the external world and putting it into a form in which it can be stored in working memory and recalled. It can be used to record external information that is needed for the domain models (i.e., without any analysis of the observations). To capture all information for a domain model at once may not be practical; this task allows the capture of specific observations in working memory as required during interactive training situations. This task is a necessary precursor to the other tasks in the classification.
  • To Interpret: This task interprets the initial domain model. It is the process of recognising the current working memory state from observations. The state can be in a number of different formats (e.g., qualitative or quantitative) depending upon the intended use of the information. Information from the domain can be transformed into recognised case-models (e.g., definitions, topics, components). Sensory data validation or correlation analysis is also part of this primitive task.
  • To Diagnose: This task extends the domain model with past values. This involves determining the former state values (numerical, qualitative or symbolic) from the current problem solving state of the training domain. It can be used to determine the defects and causes of a given problem situation. In the QUIC project, this task is called “identification”. It is re-named here to avoid confusion with the “interpretation” task.
  • To Predict: This task extends the domain model with future values. This is the opposite of a diagnosing tasks. Prospective state values are estimated or predicted from the current problem solving state of the training domain. It can be used to determine potential fixes and preventions for a given problem situation.
  • To Decide: This task extends the domain model with the process of generating conclusions from the interpreted, diagnosed and predicted problem solving state of the training domain.
  • To Execute: Once decisions have been made the process of turning these into actions (e.g., checks, repairs) has to be performed. This may be a direct translation of decisions or may involve prioritising or ordering of actions. It is the opposite of the acquisition task; i.e., putting state into actions rather than observations into state.

A summary of the task decomposition structure is shown in Figure 7-2.

Figure 7-2 Tasks in Problem Spaces (modified from [Leitch & Gallanti 1992])

Figure 7-2 Tasks in Problem Spaces (modified from [Leitch & Gallanti 1992])

The six primitive tasks have the advantage of being complete, with respect to time (current, past & future states) and specialisation [MOBIT 1994, W8]. With these tasks, actions to be performed by the trainee can be unambiguously stated. Selection or arrangements of a set of generic tasks can be found for any training objective. It should also be clear that each of these six tasks can be further decomposed into a combination of the same primitive tasks. For example, a decision task can itself be decomposed into a set of sub-tasks (e.g., into interpretation, identification and decision). This leads to a hierarchical decomposition of the training goals until a base level is achieved. The base level is to be considered to be achievable by simple training units using one type of expertise and one learning mode.

© | | Sitemap