The WorkOrder template describes how to represent a work order - the authority to
undertake
some work and the activity authorized by the work order.
The WorkOrder is one of a set of templates
used to represent activities. These are summarized in Figure 1
which shows that the model contains templates for:
- representing request and authority for work,
- managed planned authorized activities and a corresponding record of the work done,
- unmanaged planned activities and a corresponding record of the activity done,
- record of activities performed by a product.
The actual templates are:
-
Managed work
- The WorkRequest template represents a
request for work to be undertaken;
- The WorkOrder template represents the
authorization of work to be undertaken, often in response to a WorkRequest;
- The DirectedActivity template represents
an activity that is planned to be undertaken under the authority of a given
WorkOrder.
- The WorkDone template represents a record
of the work done in response to an authorized DirectedActivity.
-
UnManaged activities
- The PlannedActivity template represents an
activity that is planned to be undertaken that is neither governed by a WorkOrder nor an activity to be performed by a
product.
- The ActualActivity template represents a
record of an activity that is performed in response to a PlannedActivity.
-
Product activities
- The ActualProductUsage template represents
a record of an activity that has been performed by a product, the
usage of a product.
The SysML Block Definition diagram in Figure 2 shows how Work
order is represented in the PLCS PSM.
The following SysML Part, Reference, and Value properties are defined for this template:
References:
status [0..1] (Template: OASIS:
StateAssertion)
The status of the work order.
The reference data used in Template: OASIS:
StateAssertion is restricted as follows:
RDL constraint 1:The status is represented subclasses of State_of_work_order.
The reference data for:
OASIS:StateAssertion.sameAs -> ExternalOwlObject.individual
is restricted to the following class or a subclass:
Example reference data is:
Parts:
ids [1..*] (Template: OASIS:
Identification)
The identifiers assigned to the work order.
The reference data used in Template: OASIS:
Identification is restricted as follows:
RDL constraint 1:The ids must be classified as an Work_order_identification_code or a
subclass thereof.
The reference data for:
OASIS:Identification.role -> ExternalOwlClass.class
is restricted to the following class or a subclass:
classifications [0..*] (Template: OASIS:
Classifier)
The classification of the work order.
The reference data used in Template: OASIS:
Classifier is restricted as follows:
RDL constraint 1:The reference data for:
OASIS:Classifier.class -> ExternalOwlClass.class
is restricted to classes that are subclasses of the following class:
name [0..1] (Template: OASIS:
Name)
An optional name assigned to the work order.
Values:
dateOfIssue [0..1] (Block: Ap239Ap233Psm:
DateTimeString)
The optional date when the work order was issued.
The following constraint, normally a uniqueness constraint, is
applicable when instantiating the DateTimeString:
rule.Ap239Ap233Psm.ExternalOwlClass.ur1
Constraint: XSDDATETIMESpecification: (OCL2.0)
self.matches('[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z')