| DEX: (D004) work_package_definition — Work Package Definition | Date: 2007/09/14 16:11:29 Revision: 1.86 |
At figure 5 is diagrammatic representation of the capabilities that are required to deliver the full business scope of the DEX.
Over a period of time, work required to be undertaken on a given asset is identified from a number of sources. These include the maintenance scheduler, recorded faults, unforeseen events, change directives, etc. At some point, this work is collected together into a package and associated with a 'Support Period' window of opportunity when it is planned that the work be undertaken within an approved Work_order .
Management of the work package is modelled using these AP 239 capabilities:
A Work_order may be raised in response to one or more Work_request objects, however, a work request is not essential for the definition of the work package. It may also be the result of an approved opportunity to carry out work. A Work_order must carry the authority for the work to be done or, if appropriate, for the work to be put out to tender. The associated directive from the Work_order , modelled as a Directed_activity provides the link to the top-level asset (e.g. ship) and the focus for attaching the window of opportunity provided for by the following capability.
C020: representing_life_cycle_opportunity
This Capability models the support opportunities provided for the top-level asset as a result of logistical analysis. It defines a location, a period when the asset is planned to be present at that location and an Approval from the planning officer. This provides the window of opportunity for work to be carried out according to a package of work defined using the following capability.
This Capability delivers the core function of this component of the DEX. It defines a Scheme as the chosen_method for the Activity found at the centre of C020: representing_life_cycle_opportunity. This Scheme acts as a collector for the individual work items (activities) that are to be included in the package as well as the higher level equipment or systems which require work.
The Activity(s) represent work items and the capability provides the functionality to structure, order and define each work item using Activity(s) that are scheduled to be executed during the window of opportunity specified by the C020: representing_life_cycle_opportunity. The Activity(s) attract resources and spares etc., to be used for each item of work and also identify the specific items that require work.
The figure above attempts to provide a contextualized scoping of the various concepts within the DEX and where they may be used. Hence, the complete work package definition may encompass a Work_order , Approval, Directed_activity, a top-level asset, a life cycle opportunity and a work package. A work package may consist of a scheme of work, a version, relationships, dates, references to a piece of equipment and work items. A work item may consist of Scheme_entry(s) and relationships between them, work item definitions (activities), work item specifications (documents), calendar dates, Resource_item(s), typical tasks, references to task library items (Task_method and Task_method_version) and references to the part affected. This structure is not definitive, nor meant to be, it is designed to provide a simplistic view of how the DEX may be used. Each part above is discussed below in greater detail.
This abstract model can be related (basic framework) to a simplistic view of the schema model which provides a basic framework of how the main concepts fit together.
A Work_order may be defined in response to an issue raised through a Work_request.
A reference to a Work_request is provided by an Identification_assignment to assign an identifier (as described in C001: assigning_identifiers) to the request.
Optionally, the reference to the Work_request may have a Calendar_date assigned to the identifier. This is described in C001: assigning_identifiers.
It is possible for a single Work_order to be generated in response to many Work_request s. This is the default assumption taken within this DEX. However, where each request has a separate order, it is recommended that these be referenced.
NOTE There is no restriction on the number of orders which may be generated in response to a request.
NOTE It is not the intention of this DEX to exchange or track the status of Work_requests. It is provided here as an option, to allow for completion and interoperability with other DEXs which may generate and/or track issues raised.
Referencing Tasks within a Task Library
The LSAR (Logistic Support Analysis Record) for a complex product provides a mechanism for extensive definition of support solutions. These solutions include identification of the logistically significant items within the product and specification of the tasks that are necessary to maintain the product. These tasks are usually stored as part of a library which can be refered to when carrying out activities in accordance with the upkeep.
DEX4 provides a link between activities and tasks but does not define any information within a task. DEX3 is used to define tasks and task sets.
An instance of Activity_method and Task_method_version through an instance of Activity_method_realization.
The Activity_method_realization relationship should be classified as a library_definition (or other sub-class of activity_method_realization_code).
The Task_method_version should be identified as well as the Task_method referenced by the task_method_version.of_task_method attribute. These should be sufficient to identify a specific task within the LSAR library.
NOTE There is no definition or identification of the library where the tasks are stored (as yet). It is assumed that the receiving system will have access to the relevant library.
NOTE The definitions of a task are attached to the Task_method_version - but this is not supported by this DEX.
The default assumption in this DEX is that an Approval of the Work_order provides an automatic approval for the rest of the work package, unless one (or more) are specifically provided at a lower level (such as the Scheme or Scheme_entry or Activity level. It is a business-use decision whether the Scheme, Scheme_entry or activities require an Approval_assignment, approving the contents of the Scheme of work, work items or activities.
If the organization or agency that configures the work package is different from that which approves the Work_order , then it is possible that a separate Approval will be required. Business rules will dictate whether a Scheme_entry can have a valid Approval if (for example), the Activity and sub-activities (if defined) all carry Approval_assignments which are non-affirmative (i.e. dis-approved/rejected/unknown). SImilarly, were only a single sub-activity rejected, business rules must decide if an upper-level Approval must also be rejected.
There are mechanisms to create dependencies between different types of approvals at different levels in an instance model, but this is beyond the current version of this DEX.
© OASIS 2010 — All rights reserved