Capability (C088):— representing_task

A TASK is a description of how to do something, such as prepare an aircraft for flight, or replace a pump in a ship's engine room. In theory, the TASK can be a simple as fueling a car, or as complex as refitting a whole ship, however, TASK deliberately restricts its scope, and there are alternative capabilities designed to cover broader scopes.

A TASK is primarily concerned with the logical order of steps needed to do the job, that is, the way that one step follows from another. It does not deal with timing constraints, such as the requirement to do the task on a particular date, to spread the job out over a period of time to meet resource availability, or simply to do a collection of jobs at the same time, as, for example, a 10,000 km car service. All these requirements are covered by REPRESENTING_SCHEME.

A TASK does not represent the intention to actually do something, nor does it record that something has been done. These are covered by REPRESENTING_ACTIVITY.

This capability is further limited to recording the logical order of the task steps. Identifying the conditions for which the TASK is valid or useful, or the state of the product when the TASK is finished are covered by the capability REPRESENTING_TASK_AND_STATE. The general details of TASK and its life cycle are covered in REPRESENTING_TASK, while the many associations that can be made between a TASK and other parts of the PLCS model are covered in REPRESENTING_TASK_ASSOCIATIONS_AND_USAGE.

The result of using this capability is the ability to specify a task in detail, step by step. The meaning of characterizations of this part of the model is discussed for all stages of the life cycle. However, because of the structure of the model, the assignment of resources, etc., is covered in REPRESENTING_TASK_ASSOCIATIONS_AND_USAGE.

There is a distinction to be made between explicitly representing each task step, as provided in this capability, and recording a task description with numbered steps. In the former, each step exists in its own right and other information may be explicitly linked to each step. In the later, there is a single entity for the whole task description, and links can only be made to the description as a whole. In this case, the whole task description is either entered as a single description string, or the text is referenced as a separate document, as described in REPRESENTING_TASK. This approach may well be adequate for many applications, and corresponds to the level of control provided by older systems. This capability is provided for applications where more fine grained control is needed, such as the allocation of resources during a particular step.

Information model overview

This section provides an overview of the information model that supports this capability.

Model Overview

Figure 1 shows most of the relevant section of the Task_specification module. It contains only two distinct entities: Task, which provides the identifier for the overall task, and Task_method, which describes in detail the steps that make up the task. It is a commonplace of STEP to separate the identification into one entity and the content into another, however here the terms can be confusing. In this discussion, the term "task" (uncapitalised, unlinked) will mean the user concept of both something done and its name, but the method by which it is done will correspond to the entity Task_method.

Task_method is extensively subtyped in order to provide the structures needed to describe the different ways in which tasks are structured. The links back from the subtypes to TASK_METHOD are effectively links from TASK_METHOD back to itself, and indicate that the model supports a recursive breakdown, in which each TASK_METHOD is made up from simpler TASK_METHODs which are in turn broken down, and so on. The aim of this section is to describe how to take a task description, as defined, say, by a process chart, and represent it using the Task_specification module.

A detailed description of these subtypes and their uses is given in the following sections.

Every entity discussed below is a subtype of ACTIVITY_METHOD, and so inherits the attributes name, description, consequence and purpose. These attributes may be left blank and there are no constraints on the use of the attributes except that for the subtype TASK_STEP, the attribute DESCRIPTION is renamed STEP_TEXT, and must be used to describe the step.

ADVISORY_TASK_STEP is a subtype of TASK_STEP, and so also has DESCRIPTION renamed to STEP_TEXT, and in this case, the attribute is used to provide advisory information about the TASK_STEP. TASK_METHOD also provides the option of recording notes using ADVISORY_TASK_STEP STEP_TEXT to hold such information, though in this role, the ADVISORY_TASK_STEPs do not perturb the order of steps, as they provide supporting information.

Characterizations are provided at the level of TASK_METHOD, and are described in a section below. No additional characterization is applied directly to any of the subtypes of TASK_METHOD.

It should be noted that the structures provide a straightforward mechanism for sequencing the steps of a task, and will be adequate for most purposes. It is not intended to deal some some of the more complex, hypothetical cases, such as resequencing of steps according to the impact of external events, as these go beyond the scope of established requirements.

Simple Task

The simplest task description is one consisting of a single step, where Task_method is subtyped to Task_step, and the description is then given in the step_text attribute. This is shown as an instance diagram in figure 2.

EXAMPLE

#1=TASK('Refuel', 'Refuel vehicle', '', '', #2, ());
#2=TASK_STEP('Step 1', 'Fill petrol tack', '', '', ());

Task_step inherits the attributes name, description, consequence and purpose from the supertype Activity_method. However, the optional description in Activity_method is overridden by the required attribute step_text, which contains the written description of the step.

Sequence of Tasks

The first extension from a simple task is to create a Task_method which is composed of a sequence of steps. Figure 3 shows the relationship between the process diagram for a sequence of three tasks together with the instance model and the data model. The overall task in the process diagram has three subtasks which follow sequentially. The task is described by the instance Master_task_method, which is of type Task_method_sequence, which is a subtype of Structured_task_method, which itself is a subtype of Task_method as shown in the extract from the data model diagram. Task_method_sequence has an attribute METHODS, which is a list of Task_method (note the use of EXPRESS structure list which is defined as a sequence). In the instance diagram, this is shown by the three instances labelled Subtask 1, Subtask 2 and Subtask 3 and which are attributes methods[1], methods[2] and methods[3] respectively. That is, the list structure is used to preserve the sequence of tasks in the process.

EXAMPLE

#1=TASK('Example Task', '', '', '', #2, ());
#2=TASK_METHOD_SEQUENCE('Master_task_method', '', '', '', (), (#3,#4,#5));
#3=TASK_STEP('Subtask 1', 'Do first step', '', '', ());
#4=TASK_STEP('Subtask 2', 'Do second step', '', '', ());
#5=TASK_STEP('Subtask 3', 'Do third step', '', '', ());

Note that, since a subtask is itself a TASK_METHOD, then a subtask could itself be further divided into a sequence of TASK_METHOD. That is, the structure is recursive, in which problems are sub-divided into smaller problems, and so on. Consequently, it is possible to specify a hierarchical structure of task steps, in which a task step can be decomposed into subtasks, all of which sit below it in the hierarchy. Note firstly that, in a hierarchy, a task step cannot be decomposed into a task step above itself, otherwise that would result in an infinite loop. Secondly, the specification is not a tree, since different task methods may reference a common sub-task. However, the execution of a task generates a tree of subtasks, since the common subtasks, although specified once, are repeated separately at each invocation.

The decomposition of a task into subtasks is not limited to sequences of tasks. Structures such as loops, parallel tasks streams or decision points are also permitted, based on making some task within a sequence of steps one of the other sub-types of Task_method. These are discussed in the sections below.

Branching

Branching allows the choice of doing one thing or another, following some decision. The Condition capability describes how decisions are described, and provides the results true (the condition is met) and false (the condition is not met). Task_Structure also enables a third option "the unknown case", to allow for situations where the condition cannot be evaluated. For example, the task may specify that a part is left in place if a gauge reads above the safety level or replacement if below. However, if the value cannot be checked - the gauge is broken, say - then an alternative path needs to be specified, which, for example, gives an alternative way of making the measurement. Figure 4 illustrates the process diagram and the corresponding instance diagram.

EXAMPLE

#1=TASK('Decision Example', '', '', '', #2, ());
#2=DECISION_POINT('Check for refuelling', '', '', '', (), #3, #4, #5, #6);
#3=CONDITION('Check fuel adequate', 'Does gauge read 75% full?');
#4=TASK_STEP('Do nothing', 'Do nothing', '', '', ());
#5=TASK_STEP('Refill tank', 'Refill tank', '', '', $);
#6=TASK_STEP('Unfit for use', 'Mark vehicle as unfit for use', '', '', $);

Note, task structure only supports two way condition evaluation. That is, conditions always evaluate to either TRUE or FALSE. The only way an "unknown" condition occurs is when the condition cannot be evaluated. A properly thought-out structure will include additional "guard" conditions to catch such problems before they occur. STEP supports three logic values, but it does not identify the underlying logic. Discussion with the author of part 11 indicates that the Logic of Partial Function (LPF) was intended and readers requiring a description of this can find one in "Systematic Software Development Using VDM", Cliff Jones, Prentice-Hall, 1986.

In the case where multiway choices are required, the correct way to represent it is by a series of Decision_points, as illustrated in figure 5. Here conditions are applied sequentially to identify each case of interest.

EXAMPLE

#1=TASK('Decision Example', '', '', '', #2, ());
#2=DECISION_POINT('Check for refuelling', '', '', '', (), #3, #4, #5, #6);
#3=CONDITION('Check fuel adequate', 'Does gauge read 75% full?');
#4=TASK_STEP('Do nothing', 'Do nothing', '', '', ());
#5=TASK_STEP('Refill tank', 'Refill tank', '', '', $);
#6=TASK_STEP('Unfit for use', 'Mark vehicle as unfit for use', '', '', $);

Looping

Looping controls for the repetition of some task step (or structure of steps). There are three ways to control the number of times the task step is repeated:

Note that Repeat_until must be done at least once, whereas Repeat_while - since the test occurs before the task step is done - may never actually be done. The three looping process structures and the corresponding instance diagrams are shown in figure 6. Note that the three different control structures have very similar instance diagrams, although the Repeat count has an extra attribute.

EXAMPLE

#1=TASK('Example count', '', '', '', #4, $);
#2=TASK('Example repeat', '', '', '', #5, $);
#3=TASK('Example while', '', '', '', #6, $);
#4=REPEAT_COUNT('Repeat count', 'repeat step 10 times', '', '', $, #7, 10);
#5=REPEAT_UNTIL('Repeat until', 'Repeat until full', '', 'Refill radiator after drain', $, #9, #8);
#6=REPEAT_WHILE('Repeat while', 'Repeat while not full', '', 'Ensure radiator full', $, #11, #10);
#7=TASK_STEP('Tighten', 'Tighten each nut one turn', '', '', $);
#8=CONDITION('Is full', 'Check if full');
#9=TASK_STEP('Top-up radiator', 'Add 100 ml of coolant', '', '', $);
#10=CONDITION('Is full', 'Check if full');
#11=TASK_STEP('Replenish Radiator', 'Add 100 ml coolant', $, $, $);

When considering looping structures, three variations must be considered: Loop nesting, multiple control conditions, and early exit. The looping structures provide allow only for nested loops, that is loops inside each other. Nested looping is shown in figure 7, in which each wheel on a vehicle is checked (the outer loop), and where the check consists of tightening each nut on the wheel (the inner loop).

EXAMPLE

#38=REPEAT_WHILE('', '', 'Outer loop', '', $, #39, #43);
#39=TASK_METHOD_SEQUENCE('', '', 'Outer loop sequence', '', $, (#40,#41));
#40=TASK_STEP('', '', 'Outer loop step', '', (), 'Move to next bag');
#41=REPEAT_UNTIL('', '', 'Inner loop control', '', $, #42, #44);
#42=TASK_STEP('', '', 'Inner loop step', '', $, 'remove 5 items from bag');
#43=CONDITION('While control', 'While there are more items');

An example of multiple control conditions is "Do step X 5 times, and then repeat until Y has occurred" and is a compound condition made up from a combination of two simple conditions. This may be structured either as a Repeat_count followed by a Repeat_while (since Y may ave occurred in the first 5 iterations) (figure 8a) or as a Repeat_while with a more complex condition (figure 8b). The advantage of the former, is that it may produce clearer instructions, however it is limited to controls that can be separated into loops that follow consecutively. Loops with compound conditions, such as "while X is true, but no more than 10 times", cannot be decomposed, and must use a complex condition.

EXAMPLE

#47=REPEAT_WHILE('', '', 'Simple repeat while', '', $, #50, #51);
#48=REPEAT_COUNT('', 'Do 5 times', 'Initial repeat', '', $, #50, $);
#49=TASK_METHOD_SEQUENCE('', '', 'Controlling sequence', '', $, (#48,#47));
#50=TASK_STEP('', '', 'method to be repeated', '', $, $);
#51=CONDITION('Simple condition', 'x greater than 2.5');

EXAMPLE

#50=TASK_STEP('', '', 'method to be repeated', '', $, $);
#52=REPEAT_WHILE('', '', 'Complex while', '', $, #50, #53);
#53=CONDITION('complex condition', '(do 5 times) then (while x greater than 2.5)');

It is possible to terminate a loop part way through, using a condition pointing to a loop exit. This is illustrated in Figure 9. This is often clearer than having a decision jumping to the end of the loop, combined with a complex loop exit condition. It is not possible to jump out of a loop directly to another task step.

EXAMPLE

#1=REPEAT_COUNT('', '', 'Loop control', '', $, #2, $);
#2=TASK_METHOD_SEQUENCE('', 'Controlling sequence', 'Sequence', '', $, (#3,#4,#7));
#3=TASK_STEP('', '', 'Get next', $, $, 'Get next item out of store');
#4=DECISION_POINT('', '', 'Check item', '', $, #5, #6, $, $);
#5=CONDITION('Check Item', 'Check for signs of moisture penetration');
#6=EXIT_LOOP('', 'Exit if items damp', 'Exit on damp', '', $);
#7=TASK_STEP('', '', 'Process item', '', $, 'Unpack item');

Task Invocation

Task invocation occurs when a task step invokes another separate, predefined task. This is different from using a library of predefined methods. In theory, the same TASK_METHOD could be invoked from many different tasks. This is possible in a single, closed system, where the links can be made at the implementation level. However, there is no referencing capability for TASK METHOD, since this would involve defining separate life cycles for TASK and TASK_METHOD, and so such cross referencing at TASK_METHOD level cannot be used in a distributed environment.

Task invocation has the effect that the invoked TASK is done at the place where the TASK_INVOCATION occurs. That task finishes when all the TASK_METHODS defined for the task have been completed and it "returns" to the Task_method that invoked it. The execution of the invoking task then continues with the next task step.

The invoked Task can also "return" at an early from its TASK METHOD by use of an End_task subtype, for example, if a Decision_point is reached, and the false_case_method is End_task. The effect of END_TASK is to stop all methods in the invoked TASK, and return to the invoking TASK at the point of invocation. It is recommended that END_TASK be not used in any method tree below a CONCURENT_METHODS step, as this will leave the outcome of the TASK ill-defined.

The TASK which is being invoked will generally be defined against a generic PRODUCT, identified by a TASK_ASSIGNMENT in the role of applicable_product. However where it is invoked, it is typically being invoked against a specific PRODUCT in the context of a larger PRODUCT. For example, while doing a maintenance TASK ABC, a TASK XYZ may be invoked for the Number 1 pump and then a second time for the Number 2 pump. The question is how to link the specific pump identified in the controlling TASK ABC to the general PRODUCT identified as the applicable_product for the invoked TASK XYZ. This is done by using TASK_METHOD_ASSIGNMENT to assign the particular PRODUCT to the invocation step (the TASK_INVOCATION entity), with the role task-invocation-target. The PRODUCT may itself be identified through some breakdown, and the relevant elements, as described in the capability referencing_product_breakdown_element, are also referenced using TASK_METHOD_ASSIGNMENT in the role of task-invocation-context.

Other Methods

Concurrent_methods provides a means of identifying two or more task methods as potentially being done at the same time. That is, the task methods are constrained to begin after the preceding step and finish before the succeeding step, but otherwise there is no fixed order to the tasks, and they may be done at the same time. The subtype, Simultaneous_methods enforces the constraint that the tasks are actually done at the same time.

The Advisory_task_step is used to provide additional information to the operator, for example, about Health and Safety guidelines or the use of protective equipment. The Advisory_task_step may be inserted either as a step in the task, or as ancillary information applicable to the whole of the method, in which case it is referenced through Task_method.notes[i].

Task_method_levels allows the same method to be described at different levels of detail, for example, at a detailed level for a trainee, or at a summary level for an experienced operator. Since each level is itself a TASK_METHOD, the description can be further broken down as required.

Characterization of TASK_METHOD

The lowest level PLCS implementation module is Ap239_task_specification_resourced, and this explicitly characterizes Task_method with the following, and which are described in the subsequent subsections:

The characterizations marked * are not defined through this capability, since, at the time of writing, is is recommended that these are applied at the level of the TASK, rather than TASK_METHOD. For more detail, see the appropriate sub-section.

A TASK_METHOD has no separate APPROVAL from that APPROVAL of the TASK it is part of, and such a characterization is not defined by this capability. An APPROVAL applied to a TASK_METHOD would be an approval of the TASK_METHOD and all its sub-methods, including any TASK_INVOCATION, though not of the TASK invoked. If required by a DEX, the use of APPROVAL would additionally need to define its applicability against the characterizations, usages and assignments of TASK_METHOD, and define the way the TASK_METHOD is identified.

A TASK_METHOD has no CERTIFICATION separate from that of CERTIFICATION of the TASK it is part of, and is not defined by this capability. A CERTIFICATION applied to a TASK_METHOD would be an certification of the TASK_METHOD and all its sub-methods, including any TASK_INVOCATION, though not of the TASK invoked. If required by a DEX, the use of CERTIFICATION would additionally need to define its applicability against the characterizations, usages and assignments of TASK_METHOD, and define the way the TASK_METHOD is identified.

A TASK_METHOD does not have a separately applied CONTRACT from the CONTRACT against the TASK it is part of, and is not defined by this capability. A CONTRACT applied to a TASK_METHOD would apply to the TASK_METHOD and all its sub-methods, including any TASK_INVOCATION, though not of the TASK invoked. If required by a DEX, the use of CONTRACT would additionally need to define its applicability against the characterizations, usages and assignments of TASK_METHOD, and define the way the TASK_METHOD is identified.

In the TASK life cycle, the development of any description is carried out at the level of the TASK, so DATE_OR_DATE_TIME are not used to track the development of TASK_METHOD.

While it is conceivable that a TASK_METHOD may be valid upto or from a particular date, no separate life cycle is defined for the TASK_METHOD and such validity conditions should be set at the level of the TASK. (This does not preclude the setting of validity conditions at the TASK_METHOD level, but there is no planned mechanism for sharing or exchanging such data.)

In the absence of any requirement for the application of DATE_OR_DATE_TIME to TASK_METHOD, no roles are defined for DATE_OR_DATE_TIME_ASSIGNMENT, and its use is not defined by this capability.

A TASK_METHOD does not have a PROJECT applied separately from the PROJECT applied the TASK it is used by, and is not defined by this capability. A PROJECT applied to a TASK_METHOD would apply to the TASK_METHOD and all its sub-methods, including any TASK_INVOCATION, though not of the TASK invoked. If required by a DEX, the use of PROJECT would additionally need to define its applicability against the characterizations, usages and assignments of TASK_METHOD, and define the way the TASK_METHOD is identified.

Where a person or organization has a particular role to play in the execution of a TASK_METHOD, this is defined by referencing the person or organization as a resource through a TASK_ASSIGNMENT, and classifying the TASK_ASSIGNMENT with the appropriate role. This is covered by the REPRESENTING_TASK_ASSOCIATIONS_AND_USAGE capability.

It is conceivable that a person or organization may be identified against a life cycle role such as author of a TASK_METHOD, however in the currently defined set of capabilities, the granularity of control is not defined below TASK, and the meaning of such an assertion is not defined in this capability.

The currently capability set does not provide a capability for referencing TASK_METHOD, and the TASK life cycle does not control the definition at a level of granularity below the TASK. Consequently, identification is not used to provide a unique identifier across a distributed environment, and this capability makes no provision for using identifiers as a means of locating any particular TASK_METHOD within such an environment.

While the model makes provision for direct links between TASK_METHODs through a TASK_METHOD_RELATIONSHIP, a human readable identifier for a step may be useful when performing or reporting on a TASK. In this case it is recommended that the TASK_METHOD.NAME be used to provide this.

While a security classification applied to a TASK_METHOD would classify each of its attributes, the scope of what else would be so classified is not defined. It is therefore recommended that a security classification be applied at the level of TASK, with an application scope of the whole TASK definition.

A WORK_OUTPUT assigned to a TASK_METHOD means that the WORK_OUTPUT is identified as being available/needed dealing with at the end of this TASK_METHOD , although it may have been generated by some subordinate TASK_METHOD. The usage of WORK_OUTPUT and its assigned roles are defined in the WORK_OUTPUT capability. Any consequential TASKS defined by the WORK_OUTPUT are executed, if required, as a result of the TASK_METHOD completing.

The associations for Document Element are covered in the REPRESENTING_TASK_ASSOCIATIONS capability.

A JUSTIFICATION of a TASK_METHOD describes either why the method is required in the context of the TASK or superior TASK_METHOD, or why the method was chosen over other methods. In the case of an ADVISORY_TASK_STEP, it may also justify the application of the particular advice, such as the application of particular regulations or the derogation from them. It is recommended that JUSTIFICATION against the task life cycle (that is, the reason for developing the method) is applied against the TASK as the unit of control, rather than against a TASK_METHOD.

The role of the assignment is defined by reference data through classification. The following classifications are defined as subclasses of the abstract class Justification-to-task:

The set of classifications is not exhaustive, nor are the classifications mutually exclusive.

The LOCATION at which something should or may be done at is defined through TASK_ASSOCIATION or TASK_METHOD_ASSOCIATION as defined in REPRESENTING_TASK_ASSOCIATIONS. LOCATION_ASSIGNMENT is used in conjuction with ACTIVITY_ACTUAL when recording that a TASK_METHOD occured at a particular location. The following classifications are defined as subclasses of the abstract class Location-to-task: