The Task Schema

Overview

The NPDM breaks away from the traditional view that a task is solely a sequence of steps that have to be followed. Firstly a distinction is made between what the objective of the task is and the (one or more) ways that the objective can be achieved. In very simple terms the "what is to be done" and the "how to do it" are separated. Why? So that different methods can be defined according to the situation. It is clear that different approaches will be taken to do a given job in the field or in a well-equipped base, or in the arctic versus the desert. Even differently trained personnel and the laws and other restrictions that apply may affect how the same job is done.
Once this immediate separation is made, the NPDM also allows for different approaches to do a task rather than just a pure sequence of steps. The existing approaches made use of free text plus labeled lines to allow for some sequencing changes (such as taking different routes if a test was passed). However this meant that an entirely separate and additional functionality (use of IETM approaches) was required if this variation was to be used in a computer-sensible way. Hence the NPDM provides facilities which enable the way a task is done to be "programmed". This is effectively equivalent to a simple programming language, rich enough to enable IETM style functionality to be provided directly from the data base that corresponds to the model. (Note that it is still possible to use textual descriptions only, as in the existing MIL-STD-1388 task narratives. However this reduces the potential advantages of using the NPDM.)
Thereafter, the other main component of the task area of the model is concerned with the resources necessary to do the job.

Description

The task entity is used to identify something that needs to be done. It has a subtype, logistics_task, which carries additional information, such as criticality and maximum time. Neither of these entities includes the reason why the task has to be done, some kind of anomaly, or the way in which it can be done. The way in which a task can be done is captured through the task_method entity.

The most complex area of the task part of the NPDM is the handling of how a task is done, i.e., task_method. The first thing to realize is that it is still possible to give a simple narrative description of how a task is accomplished. This is achieved using the logistics_task_method subtype of base_task_method entity. The text is then given as the value of the representation attribute. (The reason it is called a representation is that other forms of description, such as video, can also be given.)

If, however, it makes sense to divide the task up into some series of stages, each stage will also be documented using the base_task_method entity. At this point it may also be necessary to designate some of the stages as being warnings. This is done using the advisory_task_stage entity which is a subtype of the base_task_method entity. Having separated the stages of the task method, it becomes necessary to join them back up to form the method for a single task. This is achieved using the structured_task_method entity and its subtypes.

We will start with the simplest case, that of a sequence of stages which has to be followed. A task_method_sequence is used to specify a list of stages. This is one type of structured_task_method. The ordering of the stages is captured through the use of a List for the methods attribute. There is no sequence number stored so additional stages can be inserted without recourse to renumbering. A second advantage of this approach is that the same stage can be called out by several task_methods without having to duplicate the description of the stage.

There are two other major aspects to consider:

Rather than referencing a base_task_method (which is either a logistic_task_method or an advisory task_method), it is allowed to refer to another task_method_sequence. This means that sequences can be nested within each other. This is equivalent to saying, for example: "Stage 3 of this task is to do that additional sequence of tasks". (After we consider the other types of structured_task_methods it will become clear that this opens up many more possibilities than just sequences);

Instead of referring to a simple stage in a task, it is also possible to refer to another task. This might then itself have multiple methods associated with it, dependent on different situations, each of which might be formed as a sequence or other structure. This is equivalent to saying, for example: "Stage 3 of this task is to do all of that other tasks".

Both of these are aimed at two significant requirements: the reduction of duplicated descriptions (by enabling sharing of the same information) and the intelligent (electronic) processing of task descriptions (so that the LSAR can act as a direct source for interactive manuals).
Now it is appropriate to look at all the options for structuring tasks:

task_method_sequence: lists stages or tasks to be carried out in order;

concurrent_methods: gives a group of stages or tasks to be carried out during the time it takes to do the longest task;

decision_point: enables a choice between two different routes through the task, depending on the result of a test condition;

looping_method: enables one or more stages to be repeated. There are three ways of controlling the number of repeats and these can be combined:

repeat_count: repeat the task a specified number of times;

repeat_until: repeat the task until a test condition is met;

repeat_while: repeat the task while a test condition remains true.

stop_task_method: used to terminate a particular path through a task.

What is used to do the job

The other key area associated with tasks is the resources necessary to complete the task. Here the model centres around the link from the task to the resource. This is captured through the task_resource_requirement entity. This essentially says: "here is the resource needed for this task". It has a subtype which allows for the quantity of the resource to be defined. Otherwise it is assumed to be "one of" the resource.

There is a possibility to describe the requirement for the resource, to specify why it is needed and the role that it will play in the task. The likely roles are: Spare parts, consumable, test equipment, labour, safety equipment, calibration equipment, etc. The value for role is given as a separate entity, enabling a standard set of values to be defined by a given project/organisation and referenced rather than duplicated.

Given the potential number of such characteristics (see the combined data element lists of the legacy standards), the NPDM takes a more general approach. Firstly a characteristic (or one of many subtypes) is used. In general terms, this defines a name, description and value.

The NPDM allows additional tasks to be associated with required resources. Thus if a particular piece of equipment has to be calibrated before use, the calibration task can be given as a supplementary task for using the equipment. (As a consequence of this, calibration and similar tasks are not treated differently from any other task in the NPDM.) Such a supplementary task can, of course, have additional resources associated with it.

There are the following types of resource identified in the NPDM:

facility_or_infrastructure: may be a reference to a generic facility such as a 115V power supply or a generic item of infrastructure such as a dry-dock, or a specific named and located facility, such as British Aerospace Military Aircraft EF2000 assembly line at Warton, UK;

information_requirement: some information required for the task. This allows reference to drawings, wiring diagrams, manuals, etc.;

personnel_skill: labour with known skill subject and grade;

task_training: established training for a given task;

additional_skill_requirement: training specific to the task but not available at present;

product_definition_usage: the task requires a part (or sub-assembly) which is already part of an assembly (most likely that to which the task applies). This situation arises, for example, when built-in test equipment is used;

product_design_definition: the task requires an identified product.