| Capability (C015):— representing_task | Date: 2010/10/18 11:36:42 Revision: 1.31 |
This section provides a business level overview of this capability.
A task specification is a structured description of how to do something. This initial release is focused on how to perform maintenance activities, although the scope is not limited to this.
A task specification does not ask for work to be done, schedule work to be done, or initiate work being done. Nor does it record the fact that work has been done, nor the outcome of that work (although it can specify how the outcome should be recorded). Unfortunately, there is little consistency between organizations in terminology, and the terms task, work, activity etc. are used in contradictory ways in different organizations. We therefore crave your indulgence if you find our terminology confusing.
In this initial version of the capability, the focus is on the limited scope of a task specification as an electronic model of a maintenance procedure. In this respect, it covers the same area as maintenance documentation standards such as the Aircraft documentation specification S1000D. However, unlike a document, a task specification can provide direct references to things such as resources or cost properties. In an integrated software environment, when a task is scheduled, these links can be used to automatically book facilities or order spares, or to calculate the total duration and cost of the activity.
This capability provides the basics for the general description of a task specification:
This scope also includes the meta-information, such as who owns the task specification, and copyright details.
This release is restricted to the usage phase of the task specification - that is, the phase when a task specification is being used in the field, rather than the phase where the support solution is being developed. However, it is necessary to associate status to the task specification, if only to ensure obsolete specifications are not used. The section below on Task Lifecycle covers the basics needed to identify the status or a task, and trace its evolution.
This section provides an overview of the information model that supports this capability.
The basic model, shown in figure 1, provides for two levels of control:
The text describing how to perform the task itself is provided through Task_step. This capability takes a very simple approach of allowing for only a single step; the full scope for a structured specification is the subject of C088: representing_task_structure
All three entities are mutually exclusive subtypes of Activity_method, from which they inherit the attributes name, description, consequence and purpose, which are all set to ignore.
In addition, Task_method_relationship relates two Task_methods, and Task_method_version_relationship relates two Task_method_versions. These are both mutually exclusive subtypes of Activity_method_relationship from which they inherit the attributes name and description, which are set to ignore.
Links between Task_methods are typically used to record general relationships between task specifications, such as one method being an alternative to another, such as the relation between a task specification designed for in-docks maintenance to a task specification for at-sea.
Links between Task_method_versions are intended for relationships that hold only for a particular pairs of Task_method_versions, such as one variant being derived from another.
Task_objective identifies the intended result of following the task specification, such as the correction of a fault or the return to operational readiness. It's aim is to provide a search criteria for finding a task specification to achieve a particular result. Every task specification should have at least one Task_objective - the cardinality of the attribute objective is S[0:?] (rather than S[1:?]) only to allow backward compatibility with legacy systems.
The objective of Task Specification Management is to ensure the task under consideration is well defined. In practice this means that the following information is required:
The identifier, version identifier and status are mandatory in all uses of this capability. The other attributes are optional.
Task Specification Identification
Task specification identification involves the definition of the task specification identifier and version number, together
with any variant identifier. The requirements on identification are those defined in referencing_task![[warning:]](../../../../images/dex/warning.gif){kind=small}
Error C1: Capability referencing_task not in dex_index.xml
.
A task specification is a product in its own right, and so has a life cycle. The normative description of such a life cycle is beyond the scope of this capability, however, it is necessary to define a task specification status, to distinguish between a task specification in preparation, a task specification which is approved for use, and one which has been declared obsolete.
Figure 1000 shows the state model for the life cycle. It identifies three states, which are identified by subclasses of Task_life_cycle_status:
This state model does not define any business process, consequently, the actions that result in the transition from one state to another are not shown, though it is reasonable to assume a progression from one to the next. If finer grained control is needed, this should be done by creating subclasses of the three states defined above. Further, although the capability refers to approval for use, there is no definition of the process by which that approval is obtained or whether it is necessary to record such an approval, although it does describe below how to record such an approval. Further, it is possible to provide detailed control of the task specification life cycle using the state model, however this is beyond the scope of the initial release of this capability.
A major aspect of life cycle status is the definition of the data elements subject to configuration control. For example, a typical business rule forbids the changing of the order of task steps once a task specification is in use, unless a new version is created. The initial issue of this capability is focused on the usage phase of a task specification, and so is restricted to identifying the life cycle status, rather than defining the changeability criteria against each data element.
Life Cycle Status and Approval
This section describes the mandatory allocation of a status to a Task_method_version, and the option recording of the Approval of that status.
Every Task_method_version_relationship shall be in exactly one life cycle state, which shall be recorded by classification using a subclass of Task_life_cycle_status. The status corresponding to the state is applied as described in C010: assigning_reference_data.
Since in practice, one version of a task specification supercedes another, only one version of any variant if the task specification shall have the status [[Task_status_in_use]].
The approval of any particular state is provided by assigning an approval C019: assigning_approvals to the Task_method_version. The Approval should have a classification taken from Task_life_cycle_approval:
Particular business processes may apply additional subclasses of approval, to mark the stages of the development process, but these are beyond the scope of this capability.
The Approval_assignment should be classified as Task_life_cycle_approval. The Approval_status status will take one of the standard status classifications, typically, APPROVED.
An Approval is an historical record, and is not altered once created. Consequently, a task specification may have multiple Approvals recorded against it. The rules concerning the retention of each Approval are business specific, however, where Approvals are recorded, the recommended practice is to ensure that the Approval of the current status is present.
In any implementation of task specification, it is recommended that version and variant histories are recorded using Task_method_version_relationship classified by one of the following subclasses of Task_method_version_relationship_evolution:
TMV_is_a_revision of records the fact that one version immediately follows another, whereas TMV_supercedes asserts that the later version replaces an earlier version, and is used in brining an environment up-to-date.
The use of life cycle relationships is not formally supported by this version of this capability.
This initial version of the capability describes only a subset of the characterizations available.
Why the Task Specification Exists
Reasons for the existence of a Task_method may include:
In all three cases, the reason is modelled as a Justification. In the case of a description, the link via a Justification_support_assignment is to a Document_version either as descriptor or as containing the description. In the case of a support driver, the link is to the State_definition
Why a New Version has been Created
The reason for creating a new version of a task specification is record by applying a descriptor to Task_method_version_relationship, as described in C095: assigning_descriptor, using a subclass of "Progression_description" to define the role. This is shown in figure 1100 below.
The name of a task specification is the name by which the task specification is usually know. This is applied as described in C001: assigning_identifiers where the identifier is classed as [[NAME]].
The description of a task should briefly say what it does and any important features of the task, but does not describe the method by which the task is performed, nor should it substitute for a reference to any resource, method, objective, and so on, which are explicitly represented in this capability or any of the extended capabilities. The description is applies as described in C095: assigning_descriptor and is classified as [[DESCRIPTION]].
A task specification can have one or more objectives, recorded in a Task_objective. The objective is provided as an aid to searching for task specifications, and it is therefore recommend that, for a given business context, consideration is given to restricting the vocabulary of the description of the objective.
The Task_objective will have one or more descriptions applied as described in the capability C095: assigning_descriptor using the descriptor class [[DESCRIPTION]].
The Task_objective may also have a name applied, using the capability C001: assigning_identifiers classified as [[NAME]]
Additional characterizations can be applied to Task_objective, however, these are beyond the scope of this initial version of the capability.
This version of this capability describes only a limited set of meta-information that can be applied to Task_method and Task_method_version.
A Task_method and Task_method_version may have an owner applied, as described in C094: assigning_organization where the role of the owner is [[TASK_OWNER]] or [[TASK_VERSION_OWNER]]. The owner has the right to create new versions of the task specification, and to control access to that specification. Normally, only the Task_method will have an owner, however ownership can be applied to particular versions or variants, in which case the ownership is applied to the Task_method_version takes priority over that applied to the Task_method.
A Task_method and Task_method_version may have a security classification applied, as described in C073: representing_information_controls. Where a separate security classification is applied to a particular version or variant, that applied to Task_method_version takes priority over that applied to the Task_method for the information tied to the Task_method_version. Under most security regulations, the classification applied to a Task_method_version will be higher than that applied to the Task_method, since the Task_method information forms part of the Task_method_version definition. By default, the security classification applies to all attributes and characterizations described in this capability, and to each Task_method_relationship and Task_method_version_relationship, though not to the other entities referenced. It also applies to any associated Task_objective and Task_step unless these have their own security classification applied. If a different scope is required, this must be explicitly recorded in any relevant exchange agreement.
A Task_method and Task_method_version may have a copyright notice applied, as described in C073: representing_information_controls. Where a copyright notice is applied to a particular version or variant, that applied to Task_method_version takes priority over that applied to the Task_method for the information tied to the Task_method_version. By default, the copyright notice applies to all attributes and characterizations described in this capability, and to each Task_method_relationship and Task_method_version_relationship, though not to the other entities referenced. It also applies to any associated Task_objective and Task_step unless these have their own copyright notice applied. If a different scope is required, this must be explicitly recorded in any relevant exchange agreement.
Identifying the Product-In-Focus
This section is concerned with the specification of single valued properties for a task specification, such as the cost and duration. These are summary properties, applied at the level of Task_method_version, and do not account for variations in skill level, conditional steps, and so on. If required, these can be recorded against individual task steps, as described in C088: representing_task_structure.
A property may be assigned to a Task_method_version. To specify an property it is necessary to specify the type of property, the value of the property, and the units for the property. For example, a task specification has the property "task_elapsed_continuous_time" having the value "12 person hours". It is also possible to allocate a time and date and an organization to the property value identifying who provided the value and when. It is also possible to assign an effectivity to association between the property and the task specification.
Two important properties of a property are its scope and the methodology by which it is set.
The scope of a Task specification property is one of the following subclasses of task_property_scope:
Preparation tasks are those things that must be done either before the task specified is started, or to prepare a resource for use in the task. For example, things that may need to be done before the task is started may include jacking-up the platform, removing flammable stores such as fuel, opening up access panels, or preparing the environment (removing debris from the area for a field test of an aircraft engine). Things that may need to be done to prepare a resource include collecting a spare from stores, removing coatings protecting a part in storage, or calibrating a piece of test equipment.
Follow-up tasks are those things that must be done either after the task specified is completed, or must be done to dispose of an output from the task. For example, things that may need to be done after the task is finished may include closing access panels, refueling, or removing any jacks. It is a matter of business practice whether testing, inspection and calibration are included as part of the task specification, however, these will always be included in any property that has a scope of Whole-task. Follow-up tasks may also include waste disposal and return of items to stores.
Since the scope of things included in preparation and follow-up tasks will be business specific, it is recommended that a subclass or subclasses of Whole-task be used, specific to the business context.
In the case of in-scope-cumulative and In-scope-incremental, the properties refer only to task steps which are part of the task specification content. Although this capability considers only simple task specifications of a single step, more complex task structures are supported, as described in C088: representing_task_structure. This includes the invocation of other task specifications.An In-scope-incremental property considers only the cumulative values of the task steps described within the given task specification, and excludes values that could be accumulated from invoked tasks.
In-scope-cumulative properties are calculated by analysing the properties of the invoked task specifications, and adding these to the In-scope-incremental value. There are two issues that need to be noted here. Firstly, the analysis will be business specific, with different analyses of the same task giving different answers. Secondly, since the cumulative value is the result of an analysis at a particular point in time, subsequent changes to the properties of the invoked tasks will not be reflected in the property value. It is therefore recommended that a subclass of In-scope_cumulative is used, specific to the business context, and the Property_value_representation has a date/time applied in the role of "date_calculated", as described in C079: representing_properties_numerically
The methodology by which the property is set can be taken from one of the subclasses of task_property_value_methodology:
Where a property is estimated, it is recommended that the person or organization making the estimate is recorded against the property value.
Where a property is calculated, it is recommended that a subclass is used to identify the calculation methodology.
Identification of the source of the allocation is beyond the scope of this version of this capability.
A cost property assigns a monetary cost to a Task_method_version. It shall be classified as task_cost_property or a subtype thereof. The unit of the property will be the currency used, and is taken from [[table of currencies]]. To allow for changing business and economic conditions, it is recommended that the date at which the value was set is assigned to the Property_value_representation, as described in C079: representing_properties_numerically. The person or organization defining the value may also be recorded. Where the period of validity for the cost model is known - such as a fixed price over the period of a contract - this should be represented via Dated_effectivity.
In addition to a subclass of each of task_property_scope and task_property_value_methodology, the property shall also be classified with an subclass of task_cost_property:
A chargeable resource is one in which some fixed cost can be associated with the use of the resource in the specified task, and this is directly accounted for in the operation of a task. For example, the cost of a spare part, or the cost of labour, being the manhour rate times the number of man hours allocated to do the task. Ideally, these costs should also be identified against the resource. A non-chargeable cost is one which is not directly related to the consumption of a resource by the task, such as the rental costs on workshop space, or phone charges.
The calculation of the total cost will depend on accounting practice. For example, labour rates may be multiplied by an "overhead factor" to account for labour - such as storekeepers - which may not appear explicitly in the resources for the task specification.
Since the rules concerning costs vary from organization to organization, it is recommended that these classes are further subclassed in order to identify the costing practices in force.
This capability supports a relatively simple cost model, using an uncoordinated set of single valued costs. Complex cost models, such as those allowing for co-ordinated labour and materials rates, or for overhead-costs based on particular locations, are beyond the scope of this version of the capability.
A time property assigned a measure of the time taken to perform the task specified to a Task_method_version, either in terms of elapsed time, or as the effort needed.
Elapsed time is the time from the start of the task specified to its end. In addition to a subclass of each of task_property_scope and task_property_value_methodology, the property shall also be classified with an subclass of task_elapsed_time, itself a subclass of task_time_property. The subclasses of task_elapsed_time are:
task_elapsed_continuous time represents the shortest practical time to execute the task specification, assuming continuous shift working, and will normally correspond to the critical path. This will generally be used for tasks of duration less than a working day.
Task_project_time represents the elapsed time under particular working conditions, though it is generally useful only for tasks of duration of the order of a working day or longer. The elapsed time is affected by the length of the working, which in turn is affected by the urgency of the task. Consequently, it is recommended that a subclass of Task_project_time is provides in the exchange agreement to make explicit the conditions applicable.
Effort is a measure in person-minutes, hours, days, months or years required to execute the task specification. This is a single summary figure for the whole task. Details against the various skills required are beyond the scope of this version of the capability. The property of effort shall be classified by task_effort or subclass thereof. Task_effort it a subclass of task_time_property.
This section describes the minimum content needed to define a useful task specification, and is provided to give readers a single, simple introduction to the use of Task_specificaiton. More complex requirements will be satisfied through the various extension capabilities mentioned.
A Task_step is a subtype of task_element. As such, it inherits four attributes, each of which is set to /IIGNORE. A single Task_step carries the text defining the method to be used in performing the specified task as an assigned descriptor in the role [[TASK_STEP_DEFINITION]]. Other subtypes of task_element provide for a structured decomposition of a task specification, and their use is described in the extension capability C088: representing_task_structure.
The Task_step can carry with a number of advisory notices, such as safety instructions. These are represented by an Advisory_task_step which are provided as notes to the Task_step. In the case of an Advisory_task_step, the advice is applies as a descriptor in the role [[TASK_STEP_ADVICE]] rather than [[TASK_STEP_DEFINITION]].
A task specification will generally list the resources needed to perform the task, including the personnel, tools, spare parts and consumables such as lubricants or sealants. The concept of a resource is an association between a function such as a task specification and an item, such as a spare part. Links from Task_step to one or more Required_resources should be made using Required_resource_assignment. Since the concept of a required resource is itself an association between a task specification and the item required, the Required_resource itself carries the quantity needed.
Links to additional information, such as figures, can be made using a Task_element_assignment to a Document_version.
A Task_step provides , for the purposes of task management, a single, undivided text, describing how the task is performed. This does not mean that the text itself is not broken down into detailed steps, but that resources, for example, are allocated on the basis of the whole Task_step, and for the duration of that Task_step. In a simple operation of short duration, such as changing the wheel on a bicycle, this is perfectly satisfactory. In a complex operation, such as preparing an aircraft for take-off, a fuel tender is required only for a limited period, and can be used elsewhere when its part of the task is completed. In this case, creating a separate Task_step for fueling the aircraft enables this reallocation.
In the initial move from a paper based maintenance system to a fully electronic PLCS based system, it is likely that the first version of the task specification will consist of a single Task_step containing the whole of description taken from the paper system.
The description itself is applied using the capability C095: assigning_descriptor, classifying the descriptor as [[TASK_STEP_DEFINITION]]. Business rules may also require in addition explicit classification of the Task_step, for example, for safety critical operations, or when hazardous materials are used. Figure 1100 shows an instance diagram for changing a wheel (task identification and version information has been omitted).
An Advisory_task_step may be used to provide additional instructions on the way the task is executed, rather than on the particular steps of the execution. In particular, standard safety instructions, such as the need to wear safety equipment, should be included as Advisory_task_steps. The additional instructions are applied using C095: assigning_descriptor with the descriptor classified as [[TASK_STEP_ADVICE]]. Figure 1110 extends the example given in Figure 1100 with the requirement to wear knee protection.
For standard advice, Advisory_task_step may itself be identified with classification [[??]], as described in C001: assigning_identifiers and approved as described in C019: assigning_approvals.
Further characterizations of both Task_step and Advisory_task_step are discussed in the extended capability C088: representing_task_structure.
A resource is something needed to support the performance of the specified task, and can include trained personnel, tools, parts, consumables, a facility (such as hanger) and infrastructure (such as a power supply). In PLCS, a task specification references a Required_resource, which is either a specification of the resource needed, or a link to an item that can act as the resource. For example, in changing the tyre (tire in the US) on a bicycle, the following are needed:
Figure 1200 shows this, where the maintainer is specified using Type_of_person, the tyre as a part, and the tool kit and air supply by specification.
Supporting documentation can include diagrams such as exploded parts views or circuit diagrams, explanatory texts, training material, etc. In the case of an Advisory_task_step, this can be a link back to relevant legislation, a code of practice, or a risk assessment.
The association of the documentation to the task specification is done using Task_element_assignment in a role which is a subclass of [[TASK_STEP_SUPPORTING_DOCUMENTATION]]. The following is an extensible list of these subclasses for a Task_step:
The following is an extensible list of subclasses for TASK_STEP_ADVISORY_DOCUMENTATION:
The following sections define a set of templates for the capability, where a template is a specification of a set of entities that need to be instantiated to represent a given set of information.
This section specifies the template referencing_task.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to reference to a task specification.
A task specification is a structured procedural description of how to do something. A task specification does not plan, schedule, or record what is done. A typical support solution comes with a library of tasks for the support of the product, such as would be collected together in a maintenance manual. The template for referencing a task specification enables the user to reference a complete task - for example, from the manual - without having to reproduce the details of the task. These tasks may be referenced in a maintenance schedule or a statement of work.
This template assumes that each task specification is known by a unique identifier. To ensure uniqueness, the identifier is given the context of the organization that owns the identifier.
NOTE 1 There are potentially two other requirements for ways of referencing a task. Firstly, for some organizations, task numbers are unique only in the context of a particular product, and the organization may reuse the same numbers for different tasks on different product lines. This template does not allow explicit refrence to the product, however this requirement could be met by identifying the project controlling each product as an organization in its own right, which is then a component organization of the wider organization. Secondly, an organization may assign task numbers on the basis of the usage of its product within a particular end product. For example, the provider of an altimeter may provide provide a set of calibration tasks tailored to the particular aircraft it is fitted to. This could be catered for through a variant identifier rather than citing the end product explicitly, however variants are out of scope of this template. This is not to say these work rounds will be appropriate in every case, and it would be better if additional referencing templates were created. However, at the time of writing, there are no actual requirements for such templates.
The definition of a task specification may evolve over the lifetime of the support solution. This evolution is controlled by creating separate versions of a task, and declaring them fit for use, e.g. by a formal issue process. This template describes how to reference the different versions of a task specification. The version number is required. In product environments which do not record task version identifier, the recommended practice is that the version identifier be set to 1.
In the process of drafting a new version, a task specification will frequently go through several iterations. The reference to such iterations is outside the scope of this template, which is limited to the usage phase of the task specification.
A task specification may be customised for different environments, for its use with a particular product, or for a particular maintenance organization. The term variant is used to indicate a minor variation from the specification which is in use at the same time as other such variants - that is, unlike versions, variants do not supercede each other. The specification of variants, either by reference to context or by variant identifier is beyond the scope of this template.
To identify a task, the reference must explicitly include the task identifier and its version identifier. This template does not support rule based references, such as "the latest authorized version".
The use of the term version for evolution sequence and variant for concurrent variation is consistent throughout this series of specifications. However, business terminology varies widely, with terms such as version, variant, issue, revision and mark used in no consistent way. It is therefore expected that the business which use the standard will map against their terminology to that of the standard, to ensure that the standard is used consistently.
The overall description of the model is given in the capability for representing_task. The subset of the model shown here shows only the entities and attributes that need be populated to reference the task. In particular the optional attribute content is omitted, and the attribute set (S[0..?) objective is omitted (assigning objectives will be the subject of a separate template). Both Task_method and Task_method_version are subtypes of Activity_method.
In referencing a task, the target entity is the Task_method_version, that is, every reference to a task is to a specific version of the task. Referencing Task_method_version requires the instantiation of the Task_method which it is a version of, and which carries the task identifier. The Task_method_version carries the version identifier.
target
is the parameter to which the
Task_method
is bound.
target
is the parameter to which the
Task_method_version
is bound.
| Entity in path | Value | Inherited from |
| Task_method.name | '/IGNORE' | Activity_method.name |
| Task_method.description | '/IGNORE' | Activity_method.description |
| Task_method.consequence | '/IGNORE' | Activity_method.consequence |
| Task_method.purpose | '/IGNORE' | Activity_method.purpose |
| Task_method_version.name | '/IGNORE' | Activity_method.name |
| Task_method_version.description | '/IGNORE' | Activity_method.description |
| Task_method_version.consequence | '/IGNORE' | Activity_method.consequence |
| Task_method_version.purpose | '/IGNORE' | Activity_method.purpose |
This section specifies the template representing_task_simple.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent simple task specification. A task specification is a procedural description of how to do something. A simple task specification has a simple, unstructured definition, and may also identify the context in which it is used. More complex tasks are described in the various task capabilities.
A task specification does not plan, schedule, or record what is done. This template is used to define the essential information for the specification, that is:
For example, task number 123 version 2 "Change Chain" may be specified for a 'Gears-r-us' type 3 Strumly-Bowman gear fitted to a 'Muddy-Badger' model 42 bicycle, and describes the steps needed to change the sprocket chain.
The template mandates only the minimum of information, and most of the information needed for a simple task is described under the characterization section.
This template is valid only for "in-use" stage of the Task specification life cycle, and does not consider the initial development phase, the obsolescence phase, development lifecycle data nor any controls on the development process or the authorizations that record that process.
For discussion of the meaning of identification and version and the parameters involved, see the template referencing_task.
The template characterization describes a task specified as applying to a specific type of product (the affected product), that is one which can be identified by a part number, as opposed to against a general product configuration, or a task written against a specific individual, for example, as a repair for specific damage. Where the affected product is fitted to a higher level end product (e.g. the task describes how to maintain a particular type of pump when fitted in a given class of ship), the characterization also describes how to identify the higher level product.
The template characterization allows for the task instructions to be held either as unstructured text or in a separate document.
Task_method and Task_method_version provide the control entities for the task, and are the homes of the summary information covering the task as a whole. Task_element describes how to perform the task. In a simple task, this may be either a simple description of what to do, or a reference to a more detailed document. In the latter case, Task_method can be used as a proxy to track the the lifecycle and usage of a task specification held in an external documentation system.
The model shows the three entities that must be instantiated.
target
is the parameter to which the
Task_method
is bound.
target
is the parameter to which the
Task_method_version
is bound.
target
is the parameter to which the
Task_step
is bound.
| Entity in path | Value | Inherited from |
| Task_method.name | '/IGNORE' | Activity_method.name |
| Task_method.description | '/IGNORE' | Activity_method.description |
| Task_method.consequence | '/IGNORE' | Activity_method.consequence |
| Task_method.purpose | '/IGNORE' | Activity_method.purpose |
| Task_method_version.name | '/IGNORE' | Activity_method.name |
| Task_method_version.description | '/IGNORE' | Activity_method.description |
| Task_method_version.consequence | '/IGNORE' | Activity_method.consequence |
| Task_method_version.purpose | '/IGNORE' | Activity_method.purpose |
| Task_step.name | '/IGNORE' | Activity_method.name |
| Task_step.description | '/IGNORE' | Activity_method.description |
| Task_step.consequence | '/IGNORE' | Activity_method.consequence |
| Task_step.purpose | '/IGNORE' | Activity_method.purpose |
This section specifies the template representing_task_step.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a task step. A task step contains the details for a task version.
target
is the parameter to which the
Task_step
is bound.
| Entity in path | Value | Inherited from |
| Task_step.name | '/IGNORE' | Activity_method.name |
| Task_step.description | '/IGNORE' | Activity_method.description |
| Task_step.consequence | '/IGNORE' | Activity_method.consequence |
| Task_step.purpose | '/IGNORE' | Activity_method.purpose |
This section specifies the template representing_structured_task_sequential.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a structured task where the task steps are performed in sequence.
target
is the parameter to which the
Task_method
is bound.
target
is the parameter to which the
Task_method_version
is bound.
target
is the parameter to which the
Task_element_sequence
is bound.
| Entity in path | Value | Inherited from |
| Task_method.name | '/IGNORE' | Activity_method.name |
| Task_method.description | '/IGNORE' | Activity_method.description |
| Task_method.consequence | '/IGNORE' | Activity_method.consequence |
| Task_method.purpose | '/IGNORE' | Activity_method.purpose |
| Task_element_sequence.name | '/IGNORE' | Activity_method.name |
| Task_element_sequence.description | '/IGNORE' | Activity_method.description |
| Task_element_sequence.consequence | '/IGNORE' | Activity_method.consequence |
| Task_element_sequence.purpose | '/IGNORE' | Activity_method.purpose |
| Task_method_version.name | '/IGNORE' | Activity_method.name |
| Task_method_version.description | '/IGNORE' | Activity_method.description |
| Task_method_version.consequence | '/IGNORE' | Activity_method.consequence |
| Task_method_version.purpose | '/IGNORE' | Activity_method.purpose |
This section specifies the template representing_task_version_relationship.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a relationship between two Task_method_versions.
target
is the parameter to which the
Task_method_version_relationship
is bound.
| Entity in path | Value | Inherited from |
| Task_method_version_relationship.name | '/IGNORE' | Activity_method_relationship.name |
| Task_method_version_relationship.description | '/IGNORE' | Activity_method_relationship.description |
This section specifies the template representing_advisory_task_step.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent an advisory task step, Advisory_task_step, such as a warning, caution, or note.
target
is the parameter to which the
Advisory_task_step
is bound.
| Entity in path | Value | Inherited from |
| Advisory_task_step.name | '/IGNORE' | Activity_method.name |
| Advisory_task_step.description | '/IGNORE' | Activity_method.description |
| Advisory_task_step.consequence | '/IGNORE' | Activity_method.consequence |
| Advisory_task_step.purpose | '/IGNORE' | Activity_method.purpose |
The instance model in STEP XML exchange file format (ISO 10303 Part 28 ed.2 syntax) is:#15 = CLASSIFICATION_ASSIGNMENT(#16,(#13),'/IGNORE'); #13 = IDENTIFICATION_ASSIGNMENT('The Bike Company Ltd','/IGNORE','/IGNORE',(#11)); #11 = ORGANIZATION('/IGNORE','/IGNORE'); #7 = EXTERNAL_CLASS('/NULL','Task_step_identification_code','/IGNORE',#17); #6 = CLASSIFICATION_ASSIGNMENT(#7,(#4),'/IGNORE'); #4 = IDENTIFICATION_ASSIGNMENT('50','/IGNORE','/IGNORE',(#2)); #2 = ADVISORY_TASK_STEP('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$); #31 = CLASSIFICATION_ASSIGNMENT(#32,(#29),'/IGNORE'); #29 = DOCUMENT('/IGNORE','/IGNORE','Always keep both hands on handrail when utilizing product for personnel transport.'); #28 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std','/IGNORE'); #27 = EXTERNAL_CLASS('/NULL','Description','/IGNORE',#28); #26 = CLASSIFICATION_ASSIGNMENT(#27,(#24),'/IGNORE'); #24 = DOCUMENT_ASSIGNMENT(#29,#2,'/IGNORE'); #21 = EXTERNAL_CLASS('/NULL','Owner_of','/IGNORE',#17); #20 = CLASSIFICATION_ASSIGNMENT(#21,(#18),'/IGNORE'); #18 = ORGANIZATION_OR_PERSON_IN_ORGANIZATION_ASSIGNMENT(#11,'/IGNORE',(#4)); #17 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std','/IGNORE'); #16 = EXTERNAL_CLASS('/NULL','Organization_name','/IGNORE',#17); #37 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE'); #36 = EXTERNAL_CLASS('/NULL','Caution','/IGNORE',#37); #35 = CLASSIFICATION_ASSIGNMENT(#36,(#2),'/IGNORE'); #32 = EXTERNAL_CLASS('/NULL','Descriptor','/IGNORE',#17);
This section specifies the template representing_task_invocation.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent an invocation of another task_method (_version) as a task_step in the invoking task_method.
target
is the parameter to which the
Task_invocation
is bound.
| Entity in path | Value | Inherited from |
| Task_invocation.name | '/IGNORE' | Activity_method.name |
| Task_invocation.description | '/IGNORE' | Activity_method.description |
| Task_invocation.consequence | '/IGNORE' | Activity_method.consequence |
| Task_invocation.purpose | '/IGNORE' | Activity_method.purpose |
#1 = TASK_ELEMENT_SEQUENCE('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$,(#2,#3)); #2 = TASK_STEP('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$); #3 = TASK_INVOCATION('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$,#6); #4 = TASK_METHOD_VERSION('/IGNORE','/IGNORE','/IGNORE','/IGNORE',#1,#5); #5 = TASK_METHOD('/IGNORE','/IGNORE','/IGNORE','/IGNORE',()); #6 = TASK_METHOD('/IGNORE','/IGNORE','/IGNORE','/IGNORE',()); #8 = IDENTIFICATION_ASSIGNMENT('25','/IGNORE','/IGNORE',(#3)); #10 = CLASSIFICATION_ASSIGNMENT(#11,(#8),'/IGNORE'); #11 = EXTERNAL_CLASS('/NULL','Task_step_identification_code','/IGNORE',#12); #12 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std','/IGNORE'); #15 = ORGANIZATION('/IGNORE','/IGNORE'); #17 = IDENTIFICATION_ASSIGNMENT('The Bike Company Ltd','/IGNORE','/IGNORE',(#15)); #19 = CLASSIFICATION_ASSIGNMENT(#20,(#17),'/IGNORE'); #20 = EXTERNAL_CLASS('/NULL','Organization_name','/IGNORE',#12); #22 = ORGANIZATION_OR_PERSON_IN_ORGANIZATION_ASSIGNMENT(#15,'/IGNORE',(#8)); #24 = CLASSIFICATION_ASSIGNMENT(#25,(#22),'/IGNORE'); #25 = EXTERNAL_CLASS('/NULL','Owner_of','/IGNORE',#12); #28 = CLASSIFICATION_ASSIGNMENT(#29,(#3),'/IGNORE'); #29 = EXTERNAL_CLASS('/NULL','Required_condition','/IGNORE',#30); #30 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE');
This section specifies the template representing_task_element_state_relationship.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a relationship between a task element and a defined state.
target
is the parameter to which the
Task_element_state_relationship
is bound.
#1 = TASK_STEP('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$); #2 = STATE_DEFINITION('/IGNORE','/IGNORE'); #3 = TASK_ELEMENT_STATE_RELATIONSHIP(#2,#1); #5 = CLASSIFICATION_ASSIGNMENT(#6,(#3),'/IGNORE'); #6 = EXTERNAL_CLASS('/NULL','Subtask_objective_state','/IGNORE',#7); #7 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE');
This section specifies the template representing_task_element_constraint.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a constraint between two task elements within a certain context, i.e. a time lag between element steps.
target
is the parameter to which the
Element_constraint
is bound.
| Entity in path | Value | Inherited from |
| Element_constraint.name | '/IGNORE' | Activity_method_relationship.name |
| Element_constraint.description | '/IGNORE' | Activity_method_relationship.description |
#1 = TASK_ELEMENT_SEQUENCE('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$,(#2,#3)); #2 = TASK_STEP('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$); #3 = TASK_STEP('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$); #4 = ELEMENT_CONSTRAINT($,$,#3,#2,#1); #6 = CLASSIFICATION_ASSIGNMENT(#7,(#4),'/IGNORE'); #7 = EXTERNAL_CLASS('/NULL','Start','/IGNORE',#8); #8 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE');
This section specifies the template representing_task_method_state_relationship.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent a relationship between a task and a defined state.
target
is the parameter to which the
Task_method_state_relationship
is bound.
#1 = TASK_METHOD_VERSION('/IGNORE','/IGNORE','/IGNORE','/IGNORE',$,$); #2 = STATE_DEFINITION('/IGNORE','/IGNORE'); #3 = TASK_METHOD_STATE_RELATIONSHIP(#2,#1); #5 = CLASSIFICATION_ASSIGNMENT(#6,(#3),'/IGNORE'); #6 = EXTERNAL_CLASS('/NULL','Task_objective_state','/IGNORE',#7); #7 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE');
This section specifies the template assigning_task_element.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to represent the assignment of a Task_element to another item in the model.
target
is the parameter to which the
Task_element_assignment
is bound.
| Entity in path | Value | Inherited from |
| Task_element_assignment.role | '/IGNORE' | Applied_activity_method_assignment.role |
The instance model in STEP XML exchange file format (ISO 10303 Part 28 ed.2 syntax) is:#2 = TASK_ELEMENT_ASSIGNMENT(#61,(#29),'/IGNORE'); #4 = CLASSIFICATION_ASSIGNMENT(#5,(#2),'/IGNORE'); #5 = EXTERNAL_CLASS('/NULL','Subtask_target_item','/IGNORE',#6); #6 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:sample','/IGNORE'); #8 = BREAKDOWN_ELEMENT('/IGNORE','/IGNORE','/IGNORE'); #10 = IDENTIFICATION_ASSIGNMENT('Circuit breaker','/IGNORE','/IGNORE',(#8)); #12 = CLASSIFICATION_ASSIGNMENT(#13,(#10),'/IGNORE'); #13 = EXTERNAL_CLASS('/NULL','Breakdown_element_identification_code','/IGNORE',#14); #14 = EXTERNAL_CLASS_LIBRARY('urn:plcs:rdl:std','/IGNORE'); #17 = ORGANIZATION('/IGNORE','/IGNORE'); #19 = IDENTIFICATION_ASSIGNMENT($,'/IGNORE','/IGNORE',(#17)); #21 = CLASSIFICATION_ASSIGNMENT(#22,(#19),'/IGNORE'); #22 = EXTERNAL_CLASS('/NULL','Organization_name','/IGNORE',#14); #24 = ORGANIZATION_OR_PERSON_IN_ORGANIZATION_ASSIGNMENT(#17,'/IGNORE',(#10)); #26 = CLASSIFICATION_ASSIGNMENT(#27,(#24),'/IGNORE'); #27 = EXTERNAL_CLASS('/NULL','Owner_of','/IGNORE',#14); #29 = BREAKDOWN_ELEMENT_VERSION('/IGNORE','/IGNORE',#8); #31 = IDENTIFICATION_ASSIGNMENT('Unknown','/IGNORE','/IGNORE',(#29)); #33 = CLASSIFICATION_ASSIGNMENT(#34,(#31),'/IGNORE'); #34 = EXTERNAL_CLASS('/NULL','Version_identification_code','/IGNORE',#14); #38 = ORGANIZATION('/IGNORE','/IGNORE'); #40 = IDENTIFICATION_ASSIGNMENT('Unknown','/IGNORE','/IGNORE',(#38)); #42 = CLASSIFICATION_ASSIGNMENT(#22,(#40),'/IGNORE'); #45 = ORGANIZATION_OR_PERSON_IN_ORGANIZATION_ASSIGNMENT(#38,'/IGNORE',(#31)); #47 = CLASSIFICATION_ASSIGNMENT(#27,(#45),'/IGNORE'); #50 = BREAKDOWN_ELEMENT_DEFINITION('/IGNORE','/IGNORE','/IGNORE',#51,(),#29); #51 = VIEW_DEFINITION_CONTEXT('/IGNORE','/IGNORE','/IGNORE'); #53 = CLASSIFICATION_ASSIGNMENT(#54,(#51),'/IGNORE'); #54 = EXTERNAL_CLASS('/NULL','Support_stage','/IGNORE',#14); #57 = CLASSIFICATION_ASSIGNMENT(#58,(#51),'/IGNORE'); #58 = EXTERNAL_CLASS('/NULL','Product_life_cycle_support','/IGNORE',#14); #60 = BREAKDOWN_CONTEXT('/IGNORE','/IGNORE','/IGNORE',$,#50); #61 = TASK_STEP($,'Turn on electrical switch.',$,$,$);
<ap239:uos
xsi:schemaLocation="urn:iso10303-28:xs/Product_life_cycle_support arm_lf_p28xsd.xsd">
<ap239:Task_element_assignment
id="i2">
<Assigned_activity_method>
<ap239:Task_step
ref="i61"
xsi:nil="true">
</Assigned_activity_method>
<Items>
<ap239:Breakdown_element_version
ref="i29"
xsi:nil="true">
</Items>
<Role/>
</ap239:Task_element_assignment>
<ap239:Classification_assignment
id="i4">
<Assigned_class>
<ap239:External_class
ref="i5"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Task_element_assignment
ref="i2"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i5">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i6"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:External_class_library
id="i6">
<Id/>
<Description/>
</ap239:External_class_library>
<ap239:Breakdown_element
id="i8">
<Id/>
<Name/>
<Description/>
</ap239:Breakdown_element>
<ap239:Identification_assignment
id="i10">
<Identifier/>
<Role/>
<Description/>
<Items>
<ap239:Breakdown_element
ref="i8"
xsi:nil="true">
</Items>
</ap239:Identification_assignment>
<ap239:Classification_assignment
id="i12">
<Assigned_class>
<ap239:External_class
ref="i13"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Identification_assignment
ref="i10"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i13">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i14"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:External_class_library
id="i14">
<Id/>
<Description/>
</ap239:External_class_library>
<ap239:Organization
id="i17">
<Id/>
<Name/>
</ap239:Organization>
<ap239:Identification_assignment
id="i19">
<Identifier/>
<Role/>
<Description/>
<Items>
<ap239:Organization
ref="i17"
xsi:nil="true">
</Items>
</ap239:Identification_assignment>
<ap239:Classification_assignment
id="i21">
<Assigned_class>
<ap239:External_class
ref="i22"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Identification_assignment
ref="i19"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i22">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i14"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:Organization_or_person_in_organization_assignment
id="i24">
<Assigned_entity>
<ap239:Organization
ref="i17"
xsi:nil="true">
</Assigned_entity>
<Role/>
<Items>
<ap239:Identification_assignment
ref="i10"
xsi:nil="true">
</Items>
</ap239:Organization_or_person_in_organization_assignment>
<ap239:Classification_assignment
id="i26">
<Assigned_class>
<ap239:External_class
ref="i27"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Organization_or_person_in_organization_assignment
ref="i24"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i27">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i14"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:Breakdown_element_version
id="i29">
<Id/>
<Description/>
<Of_product>
<ap239:Breakdown_element
ref="i8"
xsi:nil="true">
</Of_product>
</ap239:Breakdown_element_version>
<ap239:Identification_assignment
id="i31">
<Identifier/>
<Role/>
<Description/>
<Items>
<ap239:Breakdown_element_version
ref="i29"
xsi:nil="true">
</Items>
</ap239:Identification_assignment>
<ap239:Classification_assignment
id="i33">
<Assigned_class>
<ap239:External_class
ref="i34"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Identification_assignment
ref="i31"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i34">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i14"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:Organization
id="i38">
<Id/>
<Name/>
</ap239:Organization>
<ap239:Identification_assignment
id="i40">
<Identifier/>
<Role/>
<Description/>
<Items>
<ap239:Organization
ref="i38"
xsi:nil="true">
</Items>
</ap239:Identification_assignment>
<ap239:Classification_assignment
id="i42">
<Assigned_class>
<ap239:External_class
ref="i22"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Identification_assignment
ref="i40"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:Organization_or_person_in_organization_assignment
id="i45">
<Assigned_entity>
<ap239:Organization
ref="i38"
xsi:nil="true">
</Assigned_entity>
<Role/>
<Items>
<ap239:Identification_assignment
ref="i31"
xsi:nil="true">
</Items>
</ap239:Organization_or_person_in_organization_assignment>
<ap239:Classification_assignment
id="i47">
<Assigned_class>
<ap239:External_class
ref="i27"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:Organization_or_person_in_organization_assignment
ref="i45"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:Breakdown_element_definition
id="i50">
<Id/>
<Name/>
<Additional_characterization/>
<Initial_context>
<ap239:View_definition_context
ref="i51"
xsi:nil="true">
</Initial_context>
<Additional_contexts/>
<Defined_version>
<ap239:Breakdown_element_version
ref="i29"
xsi:nil="true">
</Defined_version>
</ap239:Breakdown_element_definition>
<ap239:View_definition_context
id="i51">
<Application_domain/>
<Life_cycle_stage/>
<Description/>
</ap239:View_definition_context>
<ap239:Classification_assignment
id="i53">
<Assigned_class>
<ap239:External_class
ref="i54"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:View_definition_context
ref="i51"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i54">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i14"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:Classification_assignment
id="i57">
<Assigned_class>
<ap239:External_class
ref="i58"
xsi:nil="true">
</Assigned_class>
<Items>
<ap239:View_definition_context
ref="i51"
xsi:nil="true">
</Items>
<Role/>
</ap239:Classification_assignment>
<ap239:External_class
id="i58">
<Id/>
<Name/>
<Description/>
<External_source>
<ap239:External_class_library
ref="i14"
xsi:nil="true">
</External_source>
</ap239:External_class>
<ap239:Breakdown_context
id="i60">
<Id/>
<Name/>
<Description/>
<Breakdown>
<ap239:Breakdown_version
xsi:nil="true">
</Breakdown>
<Breakdown_element>
<ap239:Breakdown_element_definition
ref="i50"
xsi:nil="true">
</Breakdown_element>
</ap239:Breakdown_context>
<ap239:Task_step
id="i61">
<Name/>
<Description/>
<Purpose/>
</ap239:Task_step>
</ap239:uos>
NOTE this characterization is optional.
The date when the Task_element_assignment was instantiated can be represented by assigning a date using the assigning_calendar_date template with the Date_time being classified as a type of "Date actual creation" (urn:plcs:rdl:std:Date actual creation).
NOTE The assignment of dates is described the capability C036: assigning_date_time.
This capability "Representing a Task" is related to the following capabilities:
Error C1: Capability referencing_documents not in dex_index.xmlError C1: Capability referencing_resource not in dex_index.xmlError C1: Capability referencing_task not in dex_index.xmlThe following classes of reference data are required for this capability:
© OASIS 2010 — All rights reserved