Capability (C065):— representing_work_order Date: 2008/01/08 16:35:58
Revision: 1.32
CoverContentsIntro.Overview Info. modelTemplatesCapabilities.Ref. dataIssues

Business overview

This section provides a business level overview of this capability.

This capability represents authority to undertake some work.

Examples are the authorization to:

The basic business model for requesting and authorizing work that is supported by ISO 10303-239 PLCS is shown in Figure 1 and Figure 2.

First an issue is identified that requires some work to be undertaken to resolve - a work request. When the issue is identified a number of potential solutions may be proposed. Having requested some work, the work is then authorized - the work order - This is the subject of this capability. Having authorized work to take place, a series of (authorized) activities are planned. The changes that are expected as a result of the work are related to the planned activities. The planned activities are then executed and a record of each activity undertaken is maintained as well as any results of the work.



Figure 1 —  Requesting and authorizing work

Figure 1 —  Requesting and authorizing work



Figure 2 —  Requesting and authorizing work with sub-activities

Figure 2 —  Requesting and authorizing work with sub-activities

Information model overview

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

The information required to represent a request for work, the resulting work authorization and consequent work, is summarized in the EXPRESS-G diagram in Figure 3 below and described in the following sections.

The shading on the diagram indicates which parts of the model are covered by which capabilities. Namely:

NOTE    The EXPRESS-G is not complete. For the complete EXPRESS see the modules: Work request, Work request characterized, Work order, Work order characterized, Activity and Activity as realized.

The EXPRESS-G diagram in Figure 4 shows the information required to represent the work order.



Figure 3 —  EXPRESS-G for requesting, authorizing and doing work

Figure 3 —  EXPRESS-G for requesting, authorizing and doing work



Figure 4 —  EXPRESS-G for authorizing work

Figure 4 —  EXPRESS-G for authorizing work

Representing a work order

The authorization to undertake any work is represented by Work_order.

If the work is in response to issues that have been raised, the Work_order will be related to the Work_requests representing the issues.

The actual work that is being authorized is represented by a Directed_activity which is associated with the Work_order that provides the authorization. There should only be one Directed_activity associated with a Work_order

The items affected by the activity are identified by relating them to the Directed_activity by a Applied_activity_assignment relationship classified as being an "Activity input" (urn:plcs:rdl:std:Activity input) relationship.

Any items that are produced as an output from the activity are related to the Directed_activity by an Applied_activity_assignment relationship classified as being an "Activity output" (urn:plcs:rdl:std:Activity output) relationship. For example, the development of a solution may result in the new version of design. The new version of the design, represented by a Part_version, should be related to the Directed_activity by an Applied_activity_assignment relationship classified as being an "Activity output" (urn:plcs:rdl:std:Activity output) relationship.

The work authorized by the Work_order may be decomposed into a series of sub activities. The decomposition of activities is described in the capability C032: representing_activity. Each sub activity will use the Applied_activity_assignment to relate to its inputs and outputs.

Work Order Identification

An instance of Work_order is identified by an Identification_assignment and may be specified through the template assigning_identification described within the capability C001: assigning_identifiers.

The Identification_assignment is also classified using the template assigning_reference_data to provide the type of identifier. In this case it should be a "Work order identification code" (urn:plcs:rdl:std:Work order identification code) (or sub-class thereof).

Work Order Classification

The Work_order is also classified by a Classification_assignment using the template assigning_reference_data to provide the type of Work_order. Usage of a Work_order to provide a specification of work should be classified as a [Work_order_directive]
[warning:]Error RDL1: The class Work_order_directive does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
. This may contain a single work item or many.

Different types of [Work_order_directive]
[warning:]Error RDL1: The class Work_order_directive does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
can be represented by through the extension of this reference data class (See capability C010: assigning_reference_data for details), and are determined by business-specific needs. However, the following (and their sub-classes) can be considered or expanded as required;

NOTE    There should only ever be one usage of a [Work_package_order]
[warning:]Error RDL1: The class Work_package_order does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
in a work package..

Work order life cycle

There are two aspects to the life cycle of a Work_order and Directed_activity. The first is its approval status. The second is the state which reflects the completion state, i.e. whether the activity has started, finished etc.

The approval and state stages are dependent on the business processes deployed within an enterprise. An example is the Work_order may be approved for work to start, and then have the state, "started". Once the work has been completed it may have the state "completed".

Work Order Approval

An authorized Approval can be specified through the use of the template assigning_approval which is provided with the relevant documentation of how to represent an Approval within the capability C019: assigning_approvals.

The Approval_assignment links the Work_order to an Approval.

The status of the Approval is represented by an Approval_status. The value associated with the Approval_status is provided through reference data - (i.e. it is classified by a Classification_assignment) using the template assigning_reference_data. The status may be classified as one of the following:

Once a Work_order has been approved, it is expected by default, that the entire contents of the work are also approved. If there is however, another approval assigned to a specific part of the contents referred to by this order, (which has a different status) i.e. other than approved, then this is to be treated as an exception to the work approved by the order. In these cases the subject of the approval is governed appropriately.

NOTE    It is beyond the current scope of this capability to relate different approvals together in order to ensure consistency of information across other subjects of approvals. There are no constraints to ensure that approvals at one level of the model are the same as those at lower levels. This currently provides a maximum level of flexibility for interpreting the work to be done. It is recommended that approvals be used sparingly.

The authorization is represented by an Approving_person_organization which authorizes the Approval assigned to the Work_order. The Approving_person_organization provides the identity and role of the Person with the authority in the specified organization.

The Approving_person_organization may have an approval Date_time classified to provide the [Approval_sign_off_date_time]
[warning:]Error RDL1: The class Approval_sign_off_date_time does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
to indicate when the authority approved the item. Also, the Approval may have planned and actual Date_times provided. Each should be classified as [Planned_approval_date_time]
[warning:]Error RDL1: The class Planned_approval_date_time does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and [Actual_approval_date_time]
[warning:]Error RDL1: The class Actual_approval_date_time does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
respectively.

While it is not mandatory that all these dates be specified, it is recommended that for any authorised Approval, at least one of these should be provided. The Approval can be applied to the Work_order with the template assigning_approval (specified within the capability C019: assigning_approvals), the approval Date_time(s) are applied to the Approval template through a second template - the template assigning_time (specified within the capability C036: assigning_date_time).

NOTE    The model does not support any constraints about the dates provided, i.e. to ensure that the planned date is prior to the actual.

The possible types of approvals assigned to a Work_order are subject the specific business requirements, but may include [Approval_for_release]
[warning:]Error RDL1: The class Approval_for_release does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
or one of it's sub-classes such as;

Work Order Status

A State is associated with a Work_order and Directed_activity using the Applied_state_assignment as described in the capabilities C007: representing_state_type and C041: representing_state_observed and template assigning_asserted_state.

The precise meaning of a state is represented by assigning reference data to the State as described in the capability C010: assigning_reference_data and template assigning_asserted_state.

A distinction is made between states that a subject could possibly be in, the set of all states for a Work_order for example, and the actual state that the subject is in. These are referred to defined states and observed states respectively and are represented by State_definition and State_observed. An observed state is related to the defined state (State_definition), of which it is an occurrence, by State_assessment and State_assertion.

The State_assessment indicates that an assumption has been made that something, such as a Work_order, is in a state (State_observed) that resembles the state defined by the State_definition.

The State_assertion is used to assert that, based on evidence such as measurements, conditions or other states, something, such as a Work_order, is in a state (State_observed) that is equal to the state defined by the State_definition.

The representations of defined and observed states are described in the capabilities C007: representing_state_type and C041: representing_state_observed. The representation of an assessed state is detailed in the template assigning_assessed_state and the representation of an asserted state is detailed in the template assigning_asserted_state, both of which are defined within the capability C041: representing_state_observed.

The template assigning_asserted_state instantiates an instance of State_assertion which asserts that the subject is in a State_observed, that is equivalent (equal to) a pre-defined State_definition.

The possible types of State_definition for a Work_order are specified through reference data assigned to the definition. The reference data shall be based upon extensions of the class "State of work order" (urn:plcs:rdl:std:State of work order) (a sub-class of "State definition" (urn:plcs:rdl:std:State definition)).

The actual states are dependant upon the specific business context within which this DEX is based, but given the expected usage of this DEX, the states might include;

Specific business usage may not require all these, may wish to use a subset, or may need to create sub-classes (extend) the set provided.

NOTE    The asserted state of a Work_order may be conditional upon the status of a Work_order's Approval. For example, if the work order approval is "approved for review", then it may have the state "issued_for_review".

The Work_order's State_assertion shall have an assigned Calendar_date attached to record the date when the state identified was asserted. The Calendar_date shall be classified as a "Date actual assertion" (urn:plcs:rdl:std:Date actual assertion) (or a suitable sub-class thereof).

The [Asserter_of]
[warning:]Error RDL1: The class Asserter_of does not exist in RDL at URI urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
the State_assertion may also be identified through the use of the template assigning_person_in_organization as described within the capability C041: representing_state_observed.

Work_order example

An example of a Work_order authorizing work is shown in Figure 2 below. The work is to implement a configuration change. For example, fitting a new set of brakes to a bicycle to address a safety issue.

NOTE    The representation of an issue is described in C065: representing_work_order.

The authority to develop a solution is represented by an instance of a Work_order (#167). This is related to the issues that are being addressed, which in this case is the represented by the template representing_work_request.

The actual work to develop the solution is represented by an instance of Directed_activity (#165). An Activity_method is related to the Directed_activity (#165) specifying the work that is to be done.

The inputs to this activity (the items affected by it) are the version of the bike before the configuration change represented by an instance of Product_as_realized (#244). The outputs or results of undertaking the work is a new version of the bicycle, represented by an instance of Product_as_realized (#243). The inputs and outputs are related by the template assigning_activity.

NOTE    The method for representing a Product_as_realized is described in the capability C045: representing_product_as_individual.



Figure 2 —  Authorizing work.

Figure 2 —  Authorizing work.

Model Characterization

This section specifies how the information model can be further characterized by the assignment of additional information such as dates, approvals and people or organizations.

The following characterizations may apply.

Characterization: Assigning a Person or Organization (Optional)

The person or organization that raised the Work_order and the Directed_activity can be represented by assigning a Person_in_organization or Organization (using the relationship Organization_or_person_in_organization_assignment) to the Work_order and the Directed_activity.

NOTE    The assignment of a person or organization is described in the capability C016: representing_person_organization.

Characterization: Assigning Dates (Optional)

The date when the Work_order and the Directed_activity was issued can be represented by assigning a date (using the relationship Date_or_date_time_assignment) to the Work_order and the Directed_activity using the assigning_calendar_date template with the Date_time being classified as a type of "Date actual release" (urn:plcs:rdl:std:Date actual release).

NOTE    The assignment of dates is described the capability C036: assigning_date_time.

Characterization: Assigning documents (Optional)

A text string providing a description of the order can be assigned to the Work_order, by the template assigning_descriptor. If more documentation is necessary to describe the issue, documents can be assigned using the Document_assignment relationship as described in capability C005: representing_documents and template assigning_document.

Capability templates

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.

Template: representing_work_order (Short name: rep_wrk_ord)

This section specifies the template representing_work_order.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Description

This template describes how to represent a work order - the authority to undertake some work and the activity authorized by the work order.

Model diagrams
The EXPRESS-G diagram in Figure 1 shows the templates and EXPRESS entities that are required to represent the template "representing_work_order". The text highlighted in blue shows the template parameters.


Figure 1 —  An EXPRESS-G representation of the Information model for representing_work_order

Figure 1 —  An EXPRESS-G representation of the Information model for representing_work_order

The graphic for the template to be used in other EXPRESS-G diagrams is shown in Figure  2 below.


Figure 2 —   The graphical representation of representing_work_order template

Figure 2 —   The graphical representation of representing_work_order template

Input parameters
The following input parameters are defined for this template:
id (Type='STRING')
The identifier being assigned to the Work_order.
id_class_name (Type='CLASS')
The name of the class used to classify the identifier and so provide the role or reason for the identification.
The following classes and their sub-classes can be used:
classifications: "Work_order_identification_code" (urn:plcs:rdl:std:Work_order_identification_code)
id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @id_class_name class
org_id (Type='STRING')
The identifier of the organization that "owns" the identifier.
org_id_class_name (Type='CLASS')
The name of the class being used to classify the identification of the organization. For example CAGE code.
The following classes and their sub-classes can be used:
classifications: "Organization_identification_code" (urn:plcs:rdl:std:Organization_identification_code), "Organization_name" (urn:plcs:rdl:std:Organization_name)
org_id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @org_id_class_name class
date_class_name (Type='CLASS')
The name of the class defining the role of the date assigned to the Work_order E.g. the date the Work_order was issued.
The following classes and their sub-classes can be used:
classifications: "Work_order_issue_date" (urn:plcs:rdl:std:Work_order_issue_date)
date_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing @date_class_name class.
year (Type= 'TYPE (year_number)' )
The year component of the date and time the work order was issued.
month (Type= 'TYPE (month_in_year_number)' )
The month component of the date and time the work order was issued.
day (Type= 'TYPE (day_in_month_number)' )
The day component of the date and time the work order was issued.
hour (Type= 'TYPE (hour_in_day)' )
The hour component of the date and time the work order was issued.
minute (Type= 'TYPE (minute_in_hour)' , Optional)
The minute component of the date and time the work order was issued. This parameter is optional. If not given, it will remain unset.
second (Type= 'TYPE (second_in_minute)' , Optional)
The second component of the date and time the work order was issued. This parameter is optional. If not given, it will remain unset.
sense (Type= 'ENUMERATION (offset_orientation)' )
The direction that the time the work order was issued is offset from Coordinated Universal Time. Enumeration values are: 'ahead', 'exact' or 'behind'.
hour_offset (Type='INTEGER')
The number of hours by which the time the work order was issued is offset from Coordinated Universal Time.
minute_offset (Type='INTEGER', Optional)
The number of minutes by which the time the work order was issued is offset from Coordinated Universal Time. The value of this attribute need not be specified. This parameter is optional. If not given, it will remain unset.
act_id (Type='STRING')
The identifier of the activity (Directed_activity) that has been authorized by the Work_order.
act_id_class_name (Type='CLASS')
The name of the class used to classify the identifier in parameter @act_idand so provide the role or reason for the identification.
The following classes and their sub-classes can be used:
classifications: "Activity_identification_code" (urn:plcs:rdl:std:Activity_identification_code)
act_id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @act_id_class_name class
act_org_id (Type='STRING')
The identifier of the organization that "owns" the version identifier.
act_org_id_class_name (Type='CLASS')
The name of the class being used to classify the identification of the organization that "owns" the version identifier. For example CAGE code.
The following classes and their sub-classes can be used:
classifications: "Organization_identification_code" (urn:plcs:rdl:std:Organization_identification_code), "Organization_name" (urn:plcs:rdl:std:Organization_name)
act_org_id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @act_org_id_class_name class
appr_status (Type='CLASS')
The class name of the External_class corresponding to the approval status of the work order.
The following classes and their sub-classes can be used:
classifications: "State_of_approval" (urn:plcs:rdl:std:State_of_approval)
appr_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the definition of the class referenced by the parameter @status.
appr_pers_org (Type= 'SELECT (organization_or_person_in_organization_select)' )
The person or organization responsible for the approval.
input (Type= 'SELECT (activity_item)' )
The items that are affected by the work order
in_response_to (Type= 'ENTITY (Work_request)' , Optional)
The Work_request that is being addressed by the Work_order.
chosen_method (Type= 'ENTITY (Activity_method)' )
The Activity_method that specifies the approach to undertaking the work authorized by the Work_order.
Reference parameters
The following reference parameters are defined for this template:
work_order(Type='ENTITY (Work_order)')
Allow the Work_order entity instantiated in this path to be referenced when this template is used.
Note: The Work_order entity can be referenced in a template path by:
%^target = $representing_work_order.work_order%
where target is the parameter to which the Work_order is bound.
dir_act(Type='ENTITY (Directed_activity)')
Allow the Directed_activity entity instantiated in this path to be referenced when this template is used.
Note: The Directed_activity entity can be referenced in a template path by:
%^target = $representing_work_order.dir_act%
where target is the parameter to which the Directed_activity is bound.
appl_act(Type='ENTITY (Applied_activity_assignment)')
Allow the Applied_activity_assignment entity instantiated in this path to be referenced when this template is used.
Note: The Applied_activity_assignment entity can be referenced in a template path by:
%^target = $representing_work_order.appl_act%
where target is the parameter to which the Applied_activity_assignment is bound.
Uniqueness constraints

The following parameter combinations specify a uniqueness constraint:
Unique constraint: Unique directed activity
Each instance of the entity (Work_order) within the data set shall be uniquely identified by a combination of the following parameters on this template (representing_work_order) namely: act_id, act_id_class_name, act_id_ecl_id, act_org_id, act_org_id_class_name, act_org_id_ecl_id.
The instance is referenced by the following template parameter: work_order.
Unique constraint: Unique work order
Each instance of the entity (Work_order) within the data set shall be uniquely identified by a combination of the following parameters on this template (representing_work_order) namely: id, id_class_name, id_ecl_id, org_id, org_id_class_name, org_id_ecl_id.
The instance is referenced by the following template parameter: work_order.
Instantiation path
The instantiation path shown below specifies the entities that are to be instantiated by the template.
A description of templates and the syntax for the instantiation path is provided in the Reading Capability Templates help section.
-- Instantiate a Work_order
Work_order

-- Link the work_order to the work_request
Work_order.in_response_to -> @in_response_to

-- Bind the Work_order to the parameter ^work_order.
-- The parameter is a reference parameter so the Work_order
-- entity can be referred to when this template is used.
%^work_order = Work_order%
^work_order.name = '/IGNORE'
^work_order.description = '/IGNORE'

-- Identify the Work_order
/assigning_identification(
    id=@id,
    id_class_name=@id_class_name,
    id_ecl_id=@id_ecl_id,
    org_id=@org_id,
    org_id_class_name=@org_id_class_name,
    org_id_ecl_id=@org_id_ecl_id,
    items=^work_order)/

-- Assign a date to the Work_order
/assigning_time(
    date_class_name=@date_class_name,
    date_ecl_id=@date_ecl_id,
    year=@year,
    month=@month,
    day=@day,
    hour=@hour,
    minute=@minute,
    second=@second,
    sense=@sense,
    hour_offset=@hour_offset,
    minute_offset=@minute_offset,
    items=^work_order)/

-- Approve the Work_order
/assigning_approval(
    status=@appr_status,
    status_ecl_id=@appr_ecl_id,
    items=^work_order,
    person_org=@appr_pers_org)/

-- Instantiate a Directed_activity
Directed_activity

-- Link the Directed_activity to the work_order
Directed_activity.directive -> ^work_order

-- Link the Directed_activity to the activity_method
Directed_activity.chosen_method -> @chosen_method

-- Bind the Directed_activity to the parameter ^dir_act.
-- The parameter is a reference parameter so the Directed_activity
-- entity can be referred to when this template is used.
%^dir_act = Directed_activity%
^dir_act.id = '/IGNORE'
^dir_act.name = '/IGNORE'
^dir_act.description = '/IGNORE'

-- Identify the Directed_activity
/assigning_identification(
    id=@act_id,
    id_class_name=@act_id_class_name,
    id_ecl_id=@act_id_ecl_id,
    org_id=@act_org_id,
    org_id_class_name=@act_org_id_class_name,
    org_id_ecl_id=@act_org_id_ecl_id,
    items=^dir_act)/
/assigning_activity(
    role_class_name='Activity_input',
    role_ecl_id='urn:plcs:rdl:std',
    assigned_activity=^dir_act,
    items=@input)/
%^appl_act = $assigning_activity.appl_act%
The following entities are instantiated with attributes as specified:
Entity in path Value Inherited from
Work_order.name '/IGNORE' —
Work_order.description '/IGNORE' —
Directed_activity.id '/IGNORE' Activity.id
Directed_activity.name '/IGNORE' Activity.name
Directed_activity.description '/IGNORE' Activity.description
Instance diagrams
The instance diagram in Figure  3 shows an example of the EXPRESS entities and templates that are instantiated by the template:
/representing_work_order(id='WO-22', id_class_name='Work_order_identification_code', id_ecl_id='urn:plcs:rdl:std', org_id='BikeRepair Limited', org_id_class_name='Organization_name', org_id_ecl_id='urn:plcs:rdl:std', date_class_name='Date_actual_release', date_ecl_id='urn:plcs:rdl:std', year='2006', month='6', day='9', hour='9', minute='0', second='0', sense='EXACT', hour_offset='0', minute_offset='0', appr_status='Approved', appr_ecl_id='urn:plcs:rdl:std', act_id='ACT-22', act_id_class_name='Activity_identification_code', act_id_ecl_id='urn:plcs:rdl:std', act_org_id='BikeRepair Limited', act_org_id_class_name='Organization_name', act_org_id_ecl_id='urn:plcs:rdl:std', input='#244', in_response_to='@100', chosen_method='#166')/
(an illustration of the consolidated representing_work_order template is shown in Figure 4 below.)
Note that the template assigning_organization has been instantiated to indicate issuer of the Work_order. The template assigning_reference_data has been used to show that the Work_order is a configuration change


Figure 3 —  Entities instantiated by representing_work_order template

Figure 3 —  Entities instantiated by representing_work_order template

The instance diagram in Figure 4 shows the graphic symbol for the template that is to be used in other instance diagrams. The example template is:
/representing_work_order(id='WO-22', id_class_name='Work_order_identification_code', id_ecl_id='urn:plcs:rdl:std', org_id='BikeRepair Limited', org_id_class_name='Organization_name', org_id_ecl_id='urn:plcs:rdl:std', date_class_name='Date_actual_release', date_ecl_id='urn:plcs:rdl:std', year='2006', month='6', day='9', hour='9', minute='0', second='0', sense='EXACT', hour_offset='0', minute_offset='0', appr_status='Approved', appr_ecl_id='urn:plcs:rdl:std', act_id='ACT-22', act_id_class_name='Activity_identification_code', act_id_ecl_id='urn:plcs:rdl:std', act_org_id='BikeRepair Limited', act_org_id_class_name='Organization_name', act_org_id_ecl_id='urn:plcs:rdl:std', input='#244', in_response_to='@100', chosen_method='#166')/


Figure 4 —  Instantiation of representing_work_order template

Figure 4 —  Instantiation of representing_work_order template

Characterizations
The following section details how the representing_work_order template can be optionally characterized by assigning other constructs to it. These are characterizations commonly applied to the template. The ISO 10303-239 EXPRESS model may enable other assignments to the entities instantiated by the template.
The EXPRESS-G diagram in Figure 5 shows the possible characterizations of the template "representing_work_order".


Figure 5 —  Characterizations for representing_work_order template

Figure 5 —  Characterizations for representing_work_order template

The following characterizations may apply:
Characterization Assigning person or organization

NOTE   this characterization is mandatory.

The person or organization that raised the work order must be assigned to the Work_order by Person_in_organization or Organization (using the relationship Organization_or_person_in_organization_assignment) The assignment is defined by the templates assigning_organization and assigning_person_in_organization respectively.

Characterization Assigning documentation

NOTE   this characterization is optional.

A text string providing a description of the Work_order is represented by the template assigning_descriptor. If more documentation is necessary to describe the order, documents can be assigned using the Document_assignment relationship as described in the template assigning_document.

Characterization Assigning state

NOTE   this characterization is optional.

The Work_order and Directed_activity can have a state assigned to it by using the assigning_asserted_state template.

Characterization Assigning reference data

NOTE   this characterization is optional.

The Work_order and Directed_activity can be classified by using the template assigning_reference_data.

Characterization Assigning dates and times

NOTE   this characterization is optional.

The issue date of the Work_order is assigned within the template.

Additional dates and times can be associated with the Work_order and the Directed_activity by using the template assigning_time.

For example the date when the Work_order and the Directed_activity was completed can be represented by assigning a date (using the relationship Date_or_date_time_assignment) to the Work_order and the Directed_activity using the assigning_time template with the Date_time being classified as a type of "Date actual release" (urn:plcs:rdl:std:Date actual release).

NOTE    The assignment of dates is described the capability C036: assigning_date_time.

Template: referencing_work_order (Short name: ref_wrk_ord)

This section specifies the template referencing_work_order.

NOTE  An explanation of a template and the associated instantiation path is provided in the Template overview section.

Description

This template describes how to represent a reference to a work order and the associated authorised activity.

Model diagrams
The EXPRESS-G diagram in Figure 1 shows the templates and EXPRESS entities that are required to represent the template "referencing_work_order". The text highlighted in blue shows the template parameters.


Figure 1 —  An EXPRESS-G representation of the Information model for referencing_work_order

Figure 1 —  An EXPRESS-G representation of the Information model for referencing_work_order

The graphic for the template to be used in other EXPRESS-G diagrams is shown in Figure  2 below.


Figure 2 —  The graphical representation of the referencing_work_order template

Figure 2 —  The graphical representation of the referencing_work_order template

Input parameters
The following input parameters are defined for this template:
id (Type='STRING')
The identifier being assigned to the Work_order.
id_class_name (Type='CLASS')
The name of the class used to classify the identifier and so provide the role or reason for the identification.
The following classes and their sub-classes can be used:
classifications: "Work_order_identification_code" (urn:plcs:rdl:std:Work_order_identification_code)
id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @id_class_name class
org_id (Type='STRING')
The identifier of the organization that "owns" the identifier.
org_id_class_name (Type='CLASS')
The name of the class being used to classify the identification of the organization. For example CAGE code.
The following classes and their sub-classes can be used:
classifications: "Organization_identification_code" (urn:plcs:rdl:std:Organization_identification_code), "Organization_name" (urn:plcs:rdl:std:Organization_name)
org_id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @org_id_class_name class
act_id (Type='STRING')
The identifier of the activity (Directed_activity) that has been authorized by the Work_order.
act_id_class_name (Type='CLASS')
The name of the class used to classify the identifier in parameter @act_idand so provide the role or reason for the identification.
The following classes and their sub-classes can be used:
classifications: "Activity_identification_code" (urn:plcs:rdl:std:Activity_identification_code)
act_id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @act_id_class_name class
act_org_id (Type='STRING')
The identifier of the organization that "owns" the version identifier.
act_org_id_class_name (Type='CLASS')
The name of the class being used to classify the identification of the organization that "owns" the version identifier. For example CAGE code.
The following classes and their sub-classes can be used:
classifications: "Organization_identification_code" (urn:plcs:rdl:std:Organization_identification_code), "Organization_name" (urn:plcs:rdl:std:Organization_name)
act_org_id_ecl_id (Default=urn:plcs:rdl:std,Type='URN')
The identifier of the External_class_library storing the @act_org_id_class_name class
Reference parameters
The following reference parameters are defined for this template:
work_order(Type='ENTITY (Work_order)')
Allow the Work_order entity instantiated in this path to be referenced when this template is used.
Note: The Work_order entity can be referenced in a template path by:
%^target = $referencing_work_order.work_order%
where target is the parameter to which the Work_order is bound.
dir_act(Type='ENTITY (Directed_activity)')
Allow the Directed_activity entity instantiated in this path to be referenced when this template is used.
Note: The Directed_activity entity can be referenced in a template path by:
%^target = $referencing_work_order.dir_act%
where target is the parameter to which the Directed_activity is bound.
Uniqueness constraints

The following parameter combinations specify a uniqueness constraint:
Unique constraint: Unique directed activity
Each instance of the entity (Work_order) within the data set shall be uniquely identified by a combination of the following parameters on this template (referencing_work_order) namely: act_id, act_id_class_name, act_id_ecl_id, act_org_id, act_org_id_class_name, act_org_id_ecl_id.
The instance is referenced by the following template parameter: work_order.
Unique constraint: Unique work order
Each instance of the entity (Work_order) within the data set shall be uniquely identified by a combination of the following parameters on this template (referencing_work_order) namely: id, id_class_name, id_ecl_id, org_id, org_id_class_name, org_id_ecl_id.
The instance is referenced by the following template parameter: work_order.
Instantiation path
The instantiation path shown below specifies the entities that are to be instantiated by the template.
A description of templates and the syntax for the instantiation path is provided in the Reading Capability Templates help section.
-- Instantiate a Work_order
Work_order

-- Bind the Work_order to the parameter ^work_order.
-- The parameter is a reference parameter so the Work_order
-- entity can be referred to when this template is used.
%^work_order = Work_order%
^work_order.name = '/IGNORE'
^work_order.description = '/IGNORE'

-- Identify the Work_order
/assigning_identification(
    id=@id,
    id_class_name=@id_class_name,
    id_ecl_id=@id_ecl_id,
    org_id=@org_id,
    org_id_class_name=@org_id_class_name,
    org_id_ecl_id=@org_id_ecl_id,
    items=^work_order)/

-- Instantiate a Directed_activity
Directed_activity

-- Link the Directed_activity to the work_order
Directed_activity.directive -> ^work_order
Activity_method
Activity_method.name = '/IGNORE'
Activity_method.description = '/IGNORE'
Activity_method.consequence = '/IGNORE'
Activity_method.purpose = '/IGNORE'

-- Link the Directed_activity to the activity_method
Directed_activity.chosen_method -> Activity_method

-- Bind the Directed_activity to the parameter ^dir_act.
-- The parameter is a reference parameter so the Directed_activity
-- entity can be referred to when this template is used.
%^dir_act = Directed_activity%
^dir_act.id = '/IGNORE'
^dir_act.name = '/IGNORE'
^dir_act.description = '/IGNORE'

-- Identify the Directed_activity
/assigning_identification(
    id=@act_id,
    id_class_name=@act_id_class_name,
    id_ecl_id=@act_id_ecl_id,
    org_id=@act_org_id,
    org_id_class_name=@act_org_id_class_name,
    org_id_ecl_id=@act_org_id_ecl_id,
    items=^dir_act)/
The following entities are instantiated with attributes as specified:
Entity in path Value Inherited from
Work_order.name '/IGNORE' —
Work_order.description '/IGNORE' —
Activity_method.name '/IGNORE' —
Activity_method.description '/IGNORE' —
Activity_method.consequence '/IGNORE' —
Activity_method.purpose '/IGNORE' —
Directed_activity.id '/IGNORE' Activity.id
Directed_activity.name '/IGNORE' Activity.name
Directed_activity.description '/IGNORE' Activity.description
Instance diagrams
The instance diagram in Figure  3 shows an example of the EXPRESS entities and templates that are instantiated by the template:
/referencing_work_order(id='WO-22', id_class_name='Work_order_identification_code', id_ecl_id='urn:plcs:rdl:std', org_id='BikeRepair Limited', org_id_class_name='Organization_name', org_id_ecl_id='urn:plcs:rdl:std', act_id='ACT-22', act_id_class_name='Activity_identification_code', act_id_ecl_id='urn:plcs:rdl:std', act_org_id='BikeRepair Limited', act_org_id_class_name='Organization_name', act_org_id_ecl_id='urn:plcs:rdl:std')/
(an illustration of the consolidated referencing_work_order template is shown in Figure 4 below.)


Figure 3 —  Entities instantiated by referencing_work_order template

Figure 3 —  Entities instantiated by referencing_work_order template

The instance diagram in Figure 4 shows the graphic symbol for the template that is to be used in other instance diagrams. The example template is:
/referencing_work_order(id='WO-22', id_class_name='Work_order_identification_code', id_ecl_id='urn:plcs:rdl:std', org_id='BikeRepair Limited', org_id_class_name='Organization_name', org_id_ecl_id='urn:plcs:rdl:std', act_id='ACT-22', act_id_class_name='Activity_identification_code', act_id_ecl_id='urn:plcs:rdl:std', act_org_id='BikeRepair Limited', act_org_id_class_name='Organization_name', act_org_id_ecl_id='urn:plcs:rdl:std')/


Figure 4 —  Instantiation of referencing_work_order template

Figure 4 —  Instantiation of referencing_work_order template

Characterizations
No common characterizations of the template referencing_work_order have been identified. However, the ISO 10303-239 EXPRESS model may enable other assignments to the entities instantiated by the template.

Related capabilities

This capability "Representing a work_order" is related to the following capabilities:

Dependent capabilities

This capability "Representing a work_order" is dependent on the following capabilities:

Model reference data

The following classes of reference data are required for this capability:

Activity_output(urn:plcs:rdl:std:Activity_output)
An Activity_output is an Applied_activity_assignment class whose members are outputs from an Activity.
Activity_input(urn:plcs:rdl:std:Activity_input)
An Activity_input is an Applied_activity_assignment class whose members are inputs to an Activity.
Configuration_change(urn:plcs:rdl:std:Configuration_change)
A Configuration_change classifies a Directed_activity or a Work_order as being one that results in a change to the configuration of the product design and actual product.

© OASIS 2010 — All rights reserved