Issue:
NN-1 by Nigel Newling (05-11-17) [minor_technical, open] - {Type = contents}An EXPRESS-G diagram overview would be useful for the Information Model Overview section.
| Capability (C090):— representing_task_associations | Date: 2008/01/19 11:42:59 Revision: 1.4 |
This section provides a business level overview of this capability.
The specification of a TASK_METHOD is not merely a matter of saying "do this, then this", but needs to be linked to the resources needed - skilled personnel, tools, equipment, spare parts, and so on. A TASK_METHOD is one of the poles about which PLCS turns, and so, unsuprisingly, is the centre of a complex network of associations. The raw model merely asserts that these relationships may exist, but that a relationship may be given a specific meaning by classifying it, where the classification is held as reference data. The aim of this capability is to explore the legitimate meanings of these relationships, and provide the basic reference data needed. This will provide a template for implementations, which may replace or -better - extend the reference data.
Some care is needed when creating the network of associations, since there may be other ways of creating a particular association. For example, a TASK_METHOD may be associated to a RESOURCE via a TASK_ASSIGNMENT or via a RESOURCE_ASSOCIATION. In general, an attempt has been made to give each alternative a different meaning, using the rule that the assocation takes its parent entity as its focus, and then provides a role for the target. For example, a TASK_ASSIGNMENT allows a TASK_METHOD to use a RESOURCE for its execution, whereas a RESOURCE_ASSOCIATION allows a RESOURCE to identify a TASK_METHOD needed to prepare it (e.g. calibrate a test equipment). This minimises the risk of ambiguity in the relationships, and means that an interface need only provide a single mapping between an association and its implementation.
This section provides an overview of the information model that supports this capability.
At the core of TASK_SPECIFICATION are TASK_METHOD, TASK_METHOD_VERSION and TASK_ELEMENT. Each has a corresponding relationship and assignment entity, with the assignments using a common select type, TASK_ITEM. All entities are classifiable and have the capability to support multi-lingualism.
[[The model shows the characterization (additional information applicable to the entity) and usage (links from independent concepts) of the entities, except that the characterizations of TASK are covered in REPRESENTING_TASK and those of TASK_METHOD are covered in REPRESENTING_TASK_STRUCTURE.]]
A key distinction in interpreting the model is that TASK_METHOD and TASK_METHOD_VERSION define what the task is, and carries its identity, whereas TASK_ELEMENTS gives the details of what to do. As described in REPRESENTING_TASK, the simplest task consists of the TASK_METHOD entity with an associated identification and applicable product, and a single TASK_ELEMENT subtyped to TASK_STEP, supplying the description of how to do the task. This distinction results in the associations, relationships and usages having different meanings depending on whether they relate to TASK_METHOD, TASK_ELEMENT. In general, an assignment to TASK_METHOD carries a very similar meaning to TASK_METHOD_VERSION, the decision being made on the basis of whether the item assignment must stay the same in every version and variant of the task, or whether it can change from version to version.
Indeed, this capability is entirely concerned with the meaning of the associations, and these are always dependent on the source and target entities. The term "source" is used to mean the primary subject for which the association is defined, so TASK_METHOD for TASK_METHOD_ASSIGNMENT, TASK_METHOD_VERSION for TASK_METHOD_VERSION_ASSINGMENT, TASK_ELEMENT for TASK_ELEMENT_ASSIGNMENT or RESOURCE_ITEM for RESOURCE_ITEM_ASSIGNMENT. Conversely, the "target" is the thing pointed at, usually through a select type.
Since the model makes explict the types of the source and target, care is needed to avoid polluting the reference data with distinctions that can be deduced from the source or target. For example, it would be incorrect to classify a TASK_ASSOCIATION to a document as "training manual" as the "manual" is part of the definition of the docment. Rather it would be classed as "training document" with the term document being used only to avoid leaving "training" hanging by itself.
The meaning of a particular association is always given by classification, with the classification name given in reference data. In general, the classification depends on the entity types of the source and target, and is therefore applicable to all the entity subtypes, but not their supertypes. Because of the overloading of some types, such as ACTIVITY_METHOD, in some cases the meaning of a classification may be restricted to type only, in which case it will be marked as not being used for the sub-types.
One view of classification is that it provides a form of semantic subtyping. In this capability, the meaning of the classification of an association will depend only on the type of the source or target entity, and not any classification of the entity. However, where the target or source is itself an association, its particular classification is part of the overall meaning of that association. For example, a gamma radiation source may be a required resource for an inspection task; a TASK_METHOD_ASSIGNMENT classified as "inspection equipment" may be used to link the TASK_METHOD to the RESOURCE; the TASK_METHOD_ASSIGNMENT may itself have an APPROVAL with the role "Safety Approval"; thus the meaning of the APPROVAL is that it approves the gamma source as a RESOURCE in the role of "inspection equipment", but not in any other role, and only from the standpoint of a "safety approval".
An EXPRESS-G diagram overview would be useful for the Information Model Overview section.
Refers to table 1, which does not exist.
Empty entity list in usage section
Obviously this capability is still under development. However, it also appears that it still refers to the PLCS DIS model and not the IS version. For example, Task was (I think) replaced by Task_element. It is therefore, also out of date and needs to be brought upto IS level asap.
The distinction between different associations would appear to present a good opportunity to apply templates to maintain the separation suggested in the text. As a minimum, these distinctions should be backed up with relevant figures.
The overview discusses (abstractly) possible confusions with the model (e.g. entity X) and then suggests (general) rules to avoid the problems. These need explicit examples for clarification.
Hypertext links to referenced entities, attributes, reference data and to other capabilities are completly missing.
The following subsections give the detailed interpretation the meaning of the associations ordered by target.The meanings of TASK_MEHTOD_ASSIGNMENT, TASK_METHOD_VERSION_ASSIGNMENT and TASK_ELEMENT_ASSIGNMENT are differentiated from each other, and from assignments in the other direction. The definitional status is noted for each combination or major subclassifications of combination.
In many cases, it is possible to assign both a task to an entity X and X to a task. Allowing the user to make the choice would have two bad effects. Firstly, it would result in the proliferation and duplication of reference data, which would lead eventually to the standard being interpreted in different ways, thus reducing its usefulness. Secondly, it would make implementation and validation of an exchange mechanism more difficult, as both options would need to be covered.
As a general rule, if the entity X is used to define the task, then a change to X would require at least a review of the task, and possibly a change to it. That is, a change to X has an impact on the life cycle of the task, and so the association should come within the scope of the task definition. In this case TASK_METHOD_ASSIGNMENT or TASK_METHOD_VERSION_ASSIGNMENT or TASK_ELEMENT_ASSIGNMENT should be used.
Conversely, any historical record about the task or its usage comes after the task has been defined, and should use the association defined for entity X to associate it to the task.
For other cases, the weaker rule "use the association of the thing which uses the information" is used, although this may depend on the point-of-view of the implementor. There are some cases, such as associations between TASK_METHOD and RESOURCE_ITEM, where explicit guidance is given, otherwise it is recommended looking at the reference data to see if there is already an appropriate reference data class.Table 1 summarises the section.
This section covers the relationship of documents to tasks. Much of the existing support systems are document based, and so this section provides both for identifying the documents used in a manual system and for a fully electronic system which needs to reference documents supporting the task. For example, a manual system will refer to the page of the manual, the stores requisition form needed and the worksheet recording the progress of the task. A fully electronic system will have computerised these functions, but may still reference training videos, assembly diagrams, etc. In some cases, such as transportation tasks, the task will involve documentation from outside the scope of the support system, such as customs declarations.
It is possible both to assign a task to a document or a document to a task. The choice of DOCUMENT, DOCUMENT_VERSION or DOCUMENT_DEFINITION depends on the granularity of control required, and is discussed in REPRESENTING_DOCUMENTS. It is also possible to assign part of a document to a task, using PARTIAL_DOCUMENT_ASSIGNMENT. The generic term "document element" is used to cover all these possibilities.
The use of DOCUMENT_ASSIGNMENT to assign a document element to TASK_METHOD implies that the element is relevant to the TASK_METHOD as a whole, whether or not the TASK_ELEMENT has been detailed. The following classifications are defined as subclasses of Document-to-Task:
The set of classifications is not exhaustive of Document-to-class. Task-review, Task-recording and Task-record are pairwise mutually exclusive.
There is a nice distinction to be made between the recording of what was actually done (the method for ACTIVITY_ACTUAL) and the use of a recording method defined against the method for planned ACTIVITY. A Task-record provides for the latter. As this is a DOCUMENT_ASSIGNMENT, then the Task-record corresponds to a "filled-in form", where the blank form is some subclass of Task-recording.
A TASK_METHOD_ASSIGNEMNT identifies a document element as being significant for the TASK as a whole, and, in particular, covers documents used to define the TASK_METHOD, though excluding descriptions of the TASK_ELEMENT. The following classification are defined as subclasses of Task-to-Document:
The above classes are not exhaustive of Task-to-Document. The classes marked -* are pairwise mutually exclusive.
A DOCUMENT_ASSIGNMENT to a TASK_STEP provides supporting information relevant to the particular step. The following classification are defined as subclasses of Document-to-task-method:
The above classes are not exhaustive of Document-to-task-method. The classes marked -* are pairwise mutually exclusive.
TASK_ELEMENT_ASSIGNMENT to document element provides documentation specific to the step or any of its component steps. Where a step inherits a document from a higher level step, then an assignment at the level of the step overrides the inherited document - for example, where a step references a later version of a diagnosics guide. The following classification are defined as subclasses of Task-method-to-Document:
The above classes are not exhaustive of Task-method-to-Document. The classes marked -* are pairwise mutually exclusive, except for Applicable-rules and Applied-rules, which may occur together. This may happen if the rules go beyond what is explicitly mentioned in the TASK_METHOD description.
The use of a TASK_ELEMENT_ASSIGNMENT classified as "applied-rules" may also have an APPROVAL or CERTIFICATION applied to the association which confirms the validity of the claim.
A FILE can be assigned through a DOCUMENT_ASSIGNMENT or be the target of a TASK_METHOD or TASK_ELEMENT association. Currently there is no capability covering FILE.
This section covers the assignment using TASK_METHOD_ASSIGNMENT or TASK_ELEMENT_ASSIGNMENT to a specific ORGANIZATION or POSITION, and to the general concepts of ORGANIZATION_TYPE, PERSON_TYPE and POSITION_TYPE. The characterization which assigns PERSON_IN_ORGANIZATION or ORGANIZATION to TASK_METHOD and TASK_ELEMENT is discussed under REPRESENTING_TASK .
Where the reference is to a resource needed to perform the task, then this is specified by an assignment to a REQUIRED_RESOURCE or RESOURCE_ITEM, which itself is assigned to the required target. The term "resource" covers something or someone that needs to be present - or at least available to be present - otherwise the task cannot be performed. This definition classifies someone such as an inspector who signs off the task or a test driver as a resource.
Life cycle roles, such as who may approve a task definition, are covered in REPRESENTING_TASK, and are not further considered here.
This leaves three groups of roles: those that must act before the task is done, those who may act during the task execution, and those who may or should act after the task is complete. In the first category are those with some controlling or regulatory authority who need to agree the occurance or the task, such as the customer who has to agree to pay for it, or the regulatory authority to authorize the transport of certain hazzardous materials. The second category again includes regulatory authorities, who have the right to inspection while certain tasks are being performed. The third category includes the customer, who may have their own, consequential task to perform, such as collecting the product.
These roles may refer to the TASK_METHOD as a whole, or be restricted to some particular TASK_ELEMENT. In addition, a TASK_ELEMENT may require an organization or person to be informed as a result of the method being invoked, for example, where the result of a measurement exceeds allowable values, the safety authority may need to be informed.
To support this, the following reference data classes are provided:
LOCATION covers two concepts: geographical location and named place within a product (such as seat row 1). Which is being referred to is evident from the sub-type of LOCATION assigned. Location can be the source for a LOCATION_ASSIGNMENT or the target of a TASK_METHOD_ASSIGNMENTor TASK_ELEMENT_ASSIGNMENT. The use of LOCATION_ASSIGNMENT is covered in REPRESENTING_TASK and REPRESENTING_TASK_STRUCTURE. The following classification are defined as subclasses of Task-to-Location and apply to both TASK_METHOD_ASSIGNMENTor TASK_ELEMENT_ASSIGNMENT:
Task-to-Location is not exhaustive. Task-valid-at and Task-invalid-at are mutually exclusive. Other classifications are not in principle mutually exclusive.
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 assigning_task_method_version.
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 assignment relationship between a Task_method_version and the assignment target.
The diagram shows the use of a Task_method_version_assignment to link a Task_method_version to the target in the role given by the reference data.
target
is the parameter to which the
Task_method_version_assignment
is bound.
| Entity in path | Value | Inherited from |
| Task_method_version_assignment.role | '/IGNORE' | Applied_activity_method_assignment.role |
© OASIS 2010 — All rights reserved