| DEX (D004):— work_package_definition | Date: 2006/06/14 12:04:07 Revision: 1.80 |
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 ( Section: basic framework) to a simplistic view of the schema model which provides a basic framework of how the main concepts fit together.
The basic components for the definition of a scheme of work are as follows:
Each of the above components require further characterizations and supporting information to provide a full definition. References to the asset, equipment and part affected are also required in addition to the above. References to the contents of a task library may also be added to this basic structure.
The basic configuration for the representation of a work package definition is shown below.
NOTE The following are not shown above; life cycle opportunity, references to asset, equipment and parts affected, work item specifications (documents) and task library references.
The main purpose for a Work_order within this DEX is the representation of an authorization to carry out the work as defined within the work package.
The use of a Work_order is described in the capability C065: representing_work_order.
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).
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" (urn:plcs:rdl:std:Work_order_directive). This may contain a single work item or many.
Different types of "Work_order_directive" (urn:plcs:rdl:std:Work_order_directive) can be represented by this DEX 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" (urn:plcs:rdl:std:Work_package_order) in a work package..
NOTE The reference data above may require harmonisation with other rdl classes.
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 Approval_assignment shall in these circumstances be classified as a "Work_order_approval" (urn:plcs:rdl:std:Work_order_approval) (a sub-class of "Approval_assignment_role" (urn:plcs:rdl:std:Approval_assignment_role)).
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 refered 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 DEX 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" (urn:plcs:rdl:std:Approval_sign_off_date_time) 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" (urn:plcs:rdl:std:Planned_approval_date_time) and "Actual_approval_date_time" (urn:plcs:rdl:std:Actual_approval_date_time) 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" (urn:plcs:rdl:std:Approval_for_release) or one of it's sub-classes such as;
The figure below shows the basic structure of a qualified Approval for a Work_order .
NOTE The instances for classification and identification assignment are indicated in the figure, but would need to be added to complete the representation.
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 equivelant (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".
Identification of the State(s) are provided through Identification_assignment with associated classification using "State_identification_code" (urn:plcs:rdl:std:State_identification_code) or a suitable sub-class such as "Work_order_state_identification_code" (urn:plcs:rdl:std:Work_order_state_identification_code) to identify those specific to Work_order(s).
If identification of the State_definition(s) are required, this can be provided through Identification_assignment with associated classification using "State_definition_identification_code" (urn:plcs:rdl:std:State_definition_identification_code) or a suitable sub-class.
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"
(urn:plcs:rdl:std:Asserter_of) the State_assertion may also be identified through the use of the template Error T7: assigning_person_in_organization does not exist in capability: person_in_organization
assigning_person_in_organization as described within the capability C041: representing_state_observed.
Where the organization raising the Work_order is different from the approving organization, then a separate organization shall be represented using the assigning_organization template with the assigning Organization being classified as a type of "Work_order_issuing_organization_code" (urn:plcs:rdl:std:Work_order_issuing_organization_code).
If the Work_order was raised on a different date to the date provided by the Approval, a separate Calendar_date should be provided using the assigning_calendar_date template with the Date_time being classified as a type of "Work_order_issue_date" (urn:plcs:rdl:std:Work_order_issue_date).
Where the Person_in_organization raising the Work_order is different from that provided by the approving Person_in_organization, then a separate approving Person_in_organization shall be represented using the assigning_person_in_organization, template with the assigning Person_in_organization being classified as a type of "Work_order_issuing_person_code" (urn:plcs:rdl:std:Work_order_issuing_person_code).
The use of a Work_order as described in the capability C065: representing_work_order allows further information about the Work_order to be provided through a Document_assignment relationship as described within the capability referencing_documents![[warning:]](../../../../images/dex/warning.gif){kind=small}
Error C1: Capability referencing_documents not in dex_index.xml
.
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.
Related to the work order is a Directed_activity. The purpose of the directive is two-fold; firstly to link together the asset and the Scheme of work to be carried out, and secondly, to act as a focus for the determination of the opportunity for it to be carried out.
For each Work_order there shall be only one Directed_activity defined.
The Identification_assignment of the Directed_activity shall be classified as a type of "Directed_activity_identification_code" (urn:plcs:rdl:std:Directed_activity_identification_code) (or sub-class thereof).
The classification of the Directed_activity shall be classified as a type of "Directed_activity_type_code" (urn:plcs:rdl:std:Directed_activity_type_code) (or sub-class thereof).
The Directed_activity provides the link to the top-level asset upon which the work defined shall be carried out. Through an instance of Applied_activity_assignment, one to many items may be identified.
The Directed_activity shall be the related_activity for the life cycle opportunity provided by the assigning_life_cycle_opportunity template described below.
The top-level asset shall be represented (ultimately) by a realized individual product, identified by both an Identification_assignment classified as a "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code) (or sub-class thereof), and a Product_as_realized version identified by an Identification_assignment classified as a "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code) (or sub-class thereof).
The instance of Applied_activity_assignment created via the template assigning_activity, shall be classified as an "Activity_input" (urn:plcs:rdl:std:Activity_input).
NOTE A "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) is a sub-class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code).
Where the Directed_activity is also related to a "life_cycle_opportunity" (urn:plcs:rdl:std:life_cycle_opportunity) (see Section: Life Cycle Opportunity), there is no requirement to represent the top-level asset. This would duplicate the reference to the asset provided as part of the definition of the opportunity.
The Directed_activity may also be referenced by a Contract, through the use of the assigning_contract template. An identification of the Contract is provided by an Identification_assignment where the identifier shall be classified as a type of "Contract_identification_code" (urn:plcs:rdl:std:Contract_identification_code). Should a Contract exist, then the Directed_activity can be referenced by the Contract as a contract_assignment.item, where the item references a subtype of Activity, i.e. Directed_activity.
When a Directed_activity is defined in relation to a Work_order for the purpose of establishing a "Work_package_order" (urn:plcs:rdl:std:Work_package_order), then the Directed_activity chosen_method attribute shall be related to a Scheme.
For other uses, the Directed_activity chosen_method attribute may be related to a Scheme_entry.
The classification of opportunities to undertake the support work defined in a work package is found as a sub class within the general class of "life_cycle_opportunity" (urn:plcs:rdl:std:life_cycle_opportunity) associated with the product. For example, a specified period of time in a ship's programme when it is scheduled to be in port for maintenance could be classified as an "Assisted Maintenance Period". There can be a very wide range of types of such opportunities but they can all be represented using the same AP 239 constructs.
A life cycle opportunity has five basic components.
A life cycle opportunity is defined through the assigning_life_cycle_opportunity template defined by C020: representing_life_cycle_opportunity. This creates an Activity around which a Location is assigned. The Location represents the place where the opportunity exists. The period during which the opportunity exists is provided by two dates (the period) which are assigned to the Location.
This template makes extensive use of other templates to define the information indicated in the figure below. These are described sequentially following the figure.
The life cycle opportunity may be identified through the assignment of an identifier using Identification_assignment to the Activity and may be specified through the template assigning_identification described within the capability C001: assigning_identifiers.
The Identification_assignment of the Activity shall be classified as a type of "Life_cycle_opportunity_identification_code" (urn:plcs:rdl:std:Life_cycle_opportunity_identification_code).
The Activity shall also be classified by a Classification_assignment using the template assigning_reference_data to provide the type of opportunity. The Activity shall be classified as a type of "life_cycle_opportunity" (urn:plcs:rdl:std:life_cycle_opportunity).
Different types of "life_cycle_opportunity" (urn:plcs:rdl:std:life_cycle_opportunity) can be represented by this DEX 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 by business specific usage;
NOTE The RN define many opportunities as support "periods", e.g.
An instance of Approval_assignment shall relate an authorized Approval to the Activity. The Approval is to verify that the Activity, as an opportunity defined by a location and a period of time, has been built into the life cycle planning for the asset refered to, by the appropriate planning authority.
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 Activity to an Approval. The Approval_assignment shall in these circumstances be classified as a "Life_cycle_opportunity_approval" (urn:plcs:rdl:std:Life_cycle_opportunity_approval) (a sub-class of "Approval_assignment_role" (urn:plcs:rdl:std:Approval_assignment_role)).
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 types of Approval and recording of Approval dates are explained above in Section: Approvals and described further in the capability C019: assigning_approvals.
The Location is assigned to the Activity by an instance of Location_assignment which can be provided by usage of the template Error T7: assigning_location does not exist in capability: representing_location
assigning_location, defined in C027: representing_location.
The Location is identified through the assignment of an identifier which has been classified as a "Location_identification_code" (urn:plcs:rdl:std:Location_identification_code). For example, this may be the name of a location.
The assigned Location represents the place where the opportunity exists. This is defined by assigning the "Opportunity_location" (urn:plcs:rdl:std:Opportunity_location) classification to the Location_assignment.
The period during which the opportunity exists is provided by two dates (the period) represented by Calendar_dates which are assigned to the Location. This is achieved by using the assigning_calendar_date template, where the dates are classified as "Date_planned_start" (urn:plcs:rdl:std:Date_planned_start) and the "Date_planned_end" (urn:plcs:rdl:std:Date_planned_end) respectively.
NOTE Where the period of support for an asset is known, but the location is not finalized, it is recommended to use 'Unknown' as the value classified as "Location_identification_code" (urn:plcs:rdl:std:Location_identification_code).
NOTE It should be noted that the Location is considered to be an attribute of the activity to which the product has been assigned and not an attribute of the product itself.
NOTE The figure above is not complete. The notes in blue outline indicate where additional information is required. E.g the Approval does not show authorization, and the identification_assignment and classification_assignment is not shown for Activity and Calendar_dates.
Capability C027: representing_location details the alternative Location representations which may be assigned through subtypes of Location_representation (not shown). It is assumed that these are alternatives of the same Location.
EXAMPLE The following Location_representations may all point to the same Location;
NOTE There are no constraints in the model to ensure the validity of the alternate representations as being true alternative representations of the Location.
Where there is a requirement to represent several alternate Location_representations, for example, an Address_based_location_representation and a Global_location_representation, each may be classified as either a "Primary_location_representation" (urn:plcs:rdl:std:Primary_location_representation) or "Secondary_location_representation" (urn:plcs:rdl:std:Secondary_location_representation) etc., to indicate the preference of one over another. Other sub-classes can be defined as appropriate by usage demands by expanding the reference data.
However, there appears to be no mechanism to to relate the different types of Location_representation together to indicate other semantics such as the subsitution, replacement, or other potential relations (e.g. arrangement) between Location_representations. This may be the subject of an issue for consideration in the future.
NOTE
The templates defined within capability C027: representing_location for these alternative Location_representations, such as representing_organizational_location, do not include the Location assignment template Error T7: assigning_location does not exist in capability: representing_location
assigning_location described above in
Section: Location of Opportunity. They should be used together such that the (un-populated) target of the attribute alternate_location_representations from
the instance of Location provided by through template Error T7: assigning_location does not exist in capability: representing_location
assigning_location is populated by the relevant template for the alternate representation - such as representing_organizational_location. An example of this is provided in C027: representing_location.
The Activity representing the life cycle opportunity shall be related to the top-level asset through an instance of Applied_activity_assignment, which shall be classified as an "Opportunity_input" (urn:plcs:rdl:std:Opportunity_input). This can be achieved through the use of the template assigning_activity defined within capability C032: representing_activity.
The top-level asset shall be represented (ultimately) by a Product_as_individual, identified by both an Identification_assignment classified as a "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code) (or sub-class thereof), and a Product_as_realized (the version), identified by an Identification_assignment classified as a "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code) (or sub-class thereof).
NOTE A "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) is a sub-class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code).
The following figure shows an example of an opportunity being related to a directive (and the assignment of the asset).
The Activity representing the life cycle opportunity is related to the directive through an instance of Activity_relationship. The relationship shall be classified as a "Planned_opportunity" (urn:plcs:rdl:std:Planned_opportunity) (this may or may not be the same as an "Actual_opportunity" (urn:plcs:rdl:std:Actual_opportunity) which may be reported in a DEX 9 exchange).
The Activity of a planned life cycle opportunity may not be the same as that actually used. It is possible that the planned dates change, the location may change, as could the Approval, type and identification. Although these issues are outside the scope of this DEX, the method for dealing with them is recorded here until moved to the relevant capability. To address the issues, the planned opportunity may be related to an Activity_actual representing the actual opportunity used. Both the planned and actual may also be related to the Directed_activity associated with the Work_order . These relationships are identified in the figure below.
A work package is represented by an instance of Scheme (i.e. a scheme of work). The Scheme collects together all the items of work (work items) for that work package.
The representation of a Scheme is described in detail within capability C062: representing_scheme.
A Scheme shall be identified through an Identification_assignment (described earlier in Section: Identification) which is classified as a type of "Work_package_identification_code" (urn:plcs:rdl:std:Work_package_identification_code) (or sub-class thereof).
The Scheme shall also classified by a Classification_assignment (described earlier in Section: Classification) using a "Work_package" (urn:plcs:rdl:std:Work_package) (or business-derived sub-classes thereof) to provide the type of Scheme.
The are several sub-classes of "Work_package" (urn:plcs:rdl:std:Work_package) defined for RN use that may be suitable for others (or further extension), e.g.;
An instance of Scheme may be referenced by a Scheme_relationship, relating a second instance of Scheme. The relationship may be classified as a "Work_package_sequence" (urn:plcs:rdl:std:Work_package_sequence) (a sub-class of "Scheme_sequence" (urn:plcs:rdl:std:Scheme_sequence)), where the relating_scheme represents the first (head) of the sequence and the related_scheme represents the second (subsequent) in the sequence.
While it is possible to create a Work_order with several Schemes of work defined (through using more than one instance of Directed_activity, but with only a single Work_order), and this reflects the fact that many requests for work are built up over time until an opportunity arrives. However, this level of complexity is beyond the scope of the advice given in this DEX at present.
It is thus advised to have only a single Scheme of work for each Work_order. Different work packages may be related through the Scheme_relationship entity with a relationship role provided through classification. However, the model does not have any constraints that would ensure consistency between this relationship (such as a sequence between work packages), and the planning or scheduling (date-wise) of them.
An instance of Scheme shall be referenced by at least one instance of Scheme_version which shall have an identifier classified as "Work_package_version" (urn:plcs:rdl:std:Work_package_version) (or other suitable sub-class of "Scheme_version_code" (urn:plcs:rdl:std:Scheme_version_code)).
An instance of Scheme_version may be referenced by a Scheme_version_relationship, relating a second instance of Scheme_version. The relationship may be classified as a "Work_package_version_history" (urn:plcs:rdl:std:Work_package_version_history) (a sub-class of "Scheme_version_history" (urn:plcs:rdl:std:Scheme_version_history)), where the relating_scheme_version represents the new (successor) version and the related_scheme_version represents the predecessor.
A Scheme classified as a "Work_package" (urn:plcs:rdl:std:Work_package) should provide a basic plan detailing when the package of work should be carried out. To achieve this the Scheme may be related to two instances of Calendar_date , through Date_or_date_time_assignment and classified as a "Date_planned_start" (urn:plcs:rdl:std:Date_planned_start) or "Date_planned_end" (urn:plcs:rdl:std:Date_planned_end) respectively.
NOTE It is the responsibililty of the planning/approval authority to ensure that any dates provided for work package activities coincide with those of the period for support (i.e. the life cycle opportunity).
An instance of Scheme may be referenced by an Approval_assignment, approving the contents of the work package. The Approval should be classified as a "Work_package_approval" (urn:plcs:rdl:std:Work_package_approval) (or another suitable sub-class of "Scheme_approval" (urn:plcs:rdl:std:Scheme_approval)).
NOTE The Approval of the Scheme of work authorizes the full set of work items defined within the scheme, unless a contradictory Approval (i.e. anything else other than "Approved" (urn:plcs:rdl:std:Approved)) occurs within the work package.
NOTE The figure above shows the main entity instances for the identification of a Scheme, the planned start and end dates and an Approval.
An instance of Scheme may be related to a specific subject (usually the equipment) for which it may have been defined. The assigning_scheme_subject template implements the Scheme_subject_assignment to an item or items, and is described in greater detail in capability C062: representing_scheme.
This might provide a reference to a single piece of equipment typically installed on an asset, or to several references. It infers that a scheme of work may be prepared in advance of being placed within an Work_order .
In addition, each Scheme is not restricted to the number of Scheme_subject_assignment(s) that it may be related to. Hence, each Scheme may have several Scheme_subject_assignment(s) and each one may have one or more items attached.
There are several cases to consider. If the items are subject to the same characterisations, then a single instance Scheme_subject_assignment shall be used. If the items are subject to different characterizations, then multiple instances of Scheme_subject_assignment(s) shall be used.
However, the use of a Scheme_subject_assignment and the template is optional. It is in addition to the top level asset identified by the Directed_activity (described in Section: Life Cycle Directive).
The set of items representing the subjects can be used to gain a measure of the scope of the Scheme, as the subjects collected may reflect the extent to which the asset will be affected by the contents. It may form a primitive type of bill of material.
For a typical work package, however, the subjects may provide the identification of the relative position in the asset where the activities defined within the scheme are applicable. The types of items which are applicable are described in Section: Next Higher Level Equipment.
EXAMPLE An identification of the next higher level assembly/equipment from the item under maintenance, which when added to the asset identification should provide a suitable locator, e.g. HMS Ocean, Primary Supply System.
The template may be used to identify other target items for use in the assignment (e.g. resource items as shown in the figure above) to a Scheme, and are described within capability C062: representing_scheme. For example the Scheme may be designed to ensure certain resourcee items for an asset are delivered to a location within a particular time period. However, the guidance for such a usage is out of the current scope provided for in this version of the DEX.
The result may be a set of items which are used within one or more of the work items contained within the Scheme. The individual usage is provided in each of the work items (defined below).
NOTE The Scheme_subject_assignment may refer to the same item affected by a Work_request.
NOTE The above figure is not complete. It has no identification or classification details, although the latter is indicated.
The work package, implemented as a Scheme, acts as a container into which each discrete work item can be placed. A work item has two principal characteristics. It must define what work is to be done and it must identify which element in the product breakdown is the target for that work. At its simplest, this is a one to one relationship, but, in reality, common practice will often define one work specification and associate it with a number of breakdown elements or identify one element and associate it with a number of different tasks.
For Example :
A work item entered into the Scheme of work, is done so through a Scheme_entry. Each Scheme_entry is attached to the relevant Scheme_version it is defined for. Each Scheme_version can have many Scheme_entry(s) defined for it. In this manner different versions of a Scheme may attract different work items entry(s). The work item specification, is represented separately from the Scheme_entry using an instance of Activity (Activity is described below in Section: Work Item Activity).
A Scheme_entry can be viewed as a slot into which the Activity (or other item) can be assigned. Separating the entry from the content allows for different slots to be assigned the same Activity (thereby reusing the Activity definition) a number of times within a Scheme of work. Each entry, however, should have some distinctive difference from the previous one, e.g. they may occur at different times, or in a certain sequence.
For example, the activity to inspect the tension of a bicycle chain may be entered as two work items (entries), once before a part is replaced and once again afterwards. The Activity description remains identical, but the times when they are scheduled are different.
It is therefore, recommended that each Scheme_entry shall have only one item of work (activity) entered. However, each item (activity) of work may be referenced by more than one Scheme_entry_assignment. This means that a single Activity might be re-used in more than one Scheme_entry.
Hence, the Scheme_entry should collect together all the meta-information about the work to be done, whilst the Activity provides the work description and any sub-activities that the work item is decomposed into.
However, as described under the section on structure of work items, each Activity may be decomposed into sub-activities.
Each Scheme_entry shall carry an identifier classified as a "Scheme_entry_identification_code" (urn:plcs:rdl:std:Scheme_entry_identification_code) (or sub-class thereof). This can be achieved through use of the assigning_identification template.
Each Scheme_entry shall be classified as a "Scheme_entry_type_code" (urn:plcs:rdl:std:Scheme_entry_type_code) (or sub-class thereof). This can be achieved through use of the assigning_reference_data template.
Scheme_entry(s) may be classified according to one of several sub-classes currently developed for DEX4, namely;
Each Scheme_entry may be related to one or more other Scheme_entry(s). These and other relationships(s) between work items are covered in the section Relationships between Work Items and Structure of Work Items below.
Each Scheme_entry may be characterized by one or more additional Identification_assignment(s). Each should be classified as a scheme_entry_type_code (or sub-class thereof). This can be achieved through use of the assigning_identification template.
Each Scheme_entry may be characterized by one or more additional classifications. Each classification shall be a type of "Scheme_entry_type_code" (urn:plcs:rdl:std:Scheme_entry_type_code) (or sub-class thereof). For such additional classifications a generic sub-class "Entry_classification" (urn:plcs:rdl:std:Entry_classification) has been provided. Specifying sub-classes of this can be achieved through use of the assigning_reference_data template.
EXAMPLE A priority might be assigned to the work item through an instance of Classification_assignment which is assigned the class "Priority1_classification" (urn:plcs:rdl:std:Priority1_classification). This class can be defined as a sub-class of "Priority_classification" (urn:plcs:rdl:std:Priority_classification) - which is subsequently a sub-class of "Entry_classification" (urn:plcs:rdl:std:Entry_classification).
EXAMPLE Another sub-class of "Entry_classification" (urn:plcs:rdl:std:Entry_classification) can be provided to enable a "Mandatory_classification" (urn:plcs:rdl:std:Mandatory_classification) to be assigned to a work item entry. The types of mandatory classifications can then be sub-classed appropriately through use of the assigning_reference_data template.
Each Scheme_entry may be characterized by one or more Calendar_date (s). Each should be classified as either a planned_start_date or planned_end_date. This can be achieved through use of the assigning_calendar_date template.
In this context, should there be no specific dates attached to the individual instances of Activity, then this period represents the time frame for the work items to be carried out. However, if a planned_start_date and/or planned_end_date appears lower in the work item specification, that shall take precedence over corresponding ones higher up.
NOTE It is assumed that the lower order date ranges will be within those planned for above. However, there is no mechanism in the DEX at present to ensure this is the case. This may be the subject of a rule for this DEX.
Each Scheme_entry may be characterized by Approval_assignment. This can be achieved through use of the assigning_approval template.
The presence of an Approval at the Scheme_entry level may indicate that the item affected requires a different authorization than others. An Approval for adding work through a Scheme_entry at this stage of the model should be classified as a "Work_item_entry_approval" (urn:plcs:rdl:std:Work_item_entry_approval) (or other suitable sub-class of "Scheme_entry_approval" (urn:plcs:rdl:std:Scheme_entry_approval)).
A specific Approval at this or lower levels in the specification of a Scheme_entry, Activity or Activity_method, shall take precedence over corresponding ones higher up (for example, at the Scheme or Work_order level). The status of such an Approval may be;
NOTE It is assumed that the Approval of the Work_order and Scheme shall subsume all the relevant work items specified within the work package (Scheme), unless explicitly stated otherwise. This may be the subject of a rule for this DEX.
Where there is a requirement for a single scheme of work (ie. a single work package), there needs to be some control over the way the usage of the model.
If the Directed_activity references a Work_order that has been classified as a type of "Work_package_order" (urn:plcs:rdl:std:Work_package_order), then the Directed_activity chosen_method attribute shall be related to a Scheme.
For all other uses, the Directed_activity chosen_method attribute shall be related to a Scheme_entry.
In this manner, Work_orders that have built up over time can be entered into a single scheme of work, rather than into separate work packages.
While the work item entry (Scheme_entry) describes the general meta-data associated with the work, the work itself is defined by an Activity. The template assigning_scheme_entry defined within C062: representing_scheme, can be used to assign an Activity to a Scheme_entry through the usage of a Scheme_entry_assignment.
The Scheme_entry_assignment is an important aspect of the overall work specification as it enables the definition of the role that an Activity shall play. For this, the Scheme_entry_assignment is classified using the assigning_reference_data template to provide the type of role. The usage of an Activity to define work shall be distingishable by the assignment of the class "Work_item" (urn:plcs:rdl:std:Work_item) (or a suitable sub-class thereof).
Although there may be business specific sub-classes that can be defined to provide a narrower context, the following are currently provided for use (or extension);
Each work item Activity added to an entry may be decomposed into other sub-activities (explained later). The Scheme_entry_assignment classification is only designed to characterize the top-level work item. The remaining activities (if any) will normally be a breakdown of the main Activity. Other actions (instances of Activity) can be characterized as they are assigned to other instances of Scheme_entry and related to the former. These relationships between items of work are discussed below.
It maybe possible to assign more than one item to an entry using the template provided. It is also possible to assign items other an activities to an entry. However, this leads to potentially complex situations beyond the current scope of this DEX. The guidance in this DEX currently recommends that only a single instance of Activity be assigned to each Scheme_entry.
Each Scheme_entry may be related to one or more required_resource_items. This can be achieved through use of the template above.
Resources such as consumables, tools, personnel and other equipment (e.g. parts) may be associated with a Scheme_entry. Each Resource_item will require a separate assignment and hence additional use of the template provided.
Resources provided at this level of the work package definition are assumed to be resources required by all work item activities and sub-activities defined within the Scheme_entry.
To avoid over estimations of resources required, it is advised that resources be assigned using a bottom-up approach. That is, resources should be assigned to individual activities or root/parent activities - as described below. If the same resources are required by all activities defined within the work then these may be candidates for inclusion at the higher level.
However, from the perspective of downstream reporting on activities, it is recommended that the resources be explicitly identified through the activities that use them rather than at a higher level where their usage is more implicit.
Resources provided with no indication of quantity or amount are treated as single items or single unit quantities by default, unless otherwise specified. Hence any resources defined at the Scheme_entry level which are meant for each Activity defined within the entry should be cumulatively quantified.
NOTE There is no mechanism within this DEX by which to validate distribution of resource items specified at one level, with activities defined at another.
There is an implcit set of assumptions which can be used to interpret how the specification of work can be organized.
For example, instances of Scheme_entry classified as types of "Planned_maintenance" (urn:plcs:rdl:std:Planned_maintenance), will likely have predefined library definitions of the work. Hence there will likely be only a single Activity defined with no underlying decomposition.
However, instances of Scheme_entry classified as types of "Ad_hoc_maintenance" (urn:plcs:rdl:std:Ad_hoc_maintenance), will not likely have predefined library definitions of the work. Hence there will likely be a root Activity decomposed into many others.
A third possibility can also occur, where the instance of Scheme_entry classified as types of "Planned_maintenance" (urn:plcs:rdl:std:Planned_maintenance), which has a set of predefined library definitions of the work. However, local requirements dictate a departure from the library definitions which are defined through a root Activity that may have an underlying decomposition.
NOTE The departure from procedure may require a concession. See the separate section on concessions below.
Where individual items of work (represented by Scheme_entry), are required to be followed in sequence, then an instance of Sequencing_relationship should be provided between the two relevant Scheme_entry instances.
The first in the sequence should be specified as the Sequencing_relationship.relating_method.
The Sequencing_relationship should be classified as a "Scheme_entry_sequence" (urn:plcs:rdl:std:Scheme_entry_sequence) or subclass of this. For example;
The Sequencing_relationship.time_lag provides a duration of time that should be allowed between the two Scheme_entry activities. The context of the duration of time is provided by the classification of the relationship.
EXAMPLE The time_lag between the activities defined by entry 1 and entry 2 is 2 hours from finishing the Activity in entry 1 to the start of the Activity refered to in entry 2. This can be useful where specifying items of work which require a time lag, e.g. between painting primer and top coats onto a surface.
NOTE Where no time_lag instance is provided, it should be assumed that the items of work may proceed immediately in sequence.
An Activity is used to represent a planned work item. Activity_actual is used to record the actual activity which was carried out and is beyond the scope of DEX4.
A single Activity with no sub-activities (defined within the next section) is defined in conjunction with a Scheme_entry (described above). Sub-activities need not be associated directly to a Scheme_entry, but the root parent of the sub-activities shall be related to a Scheme_entry.
Each Activity shall carry an identifier classified as an "Activity_identification_code" (urn:plcs:rdl:std:Activity_identification_code). This can be achieved through use of the assigning_identification template.
For this DEX an Activity describes a "procedure" - a set of actions to be carried out. Hence each Activity shall be classified as an "Procedure" (urn:plcs:rdl:std:Procedure) (a sub-class of "Activity_type_code" (urn:plcs:rdl:std:Activity_type_code)). This can be achieved through use of the assigning_reference_data template.
The sub-classes of "Typical_procedure" (urn:plcs:rdl:std:Typical_procedure) currently defined include the following;
Relationships between work item activities are described in the Structure of Work Items (below) and Relationships between Items of Work (above).
Each Activity may be characterized by one or more additional Classification_assignment (s). Each should be classified as an activity_usage_code (or sub-class thereof). This can be achieved through use of the assigning_reference_data template.
Each Activity may be characterized by one or more additional identifiers classified as an activity_identification_code (or sub-class thereof). This can be achieved through use of the assigning_identification template.
Each Activity may be characterized by one or more Calendar_date (s). Each should be classified as either a planned_start_date or planned_end_date. This can be achieved through use of the assigning_calendar_date template. Dates attached to the individual instances of Activity, overide those defined higher up in the chain.
EXAMPLE For example, if this were a sub-activity then this period will overide any dates specified at the next parent Activity.
Should no dates be provided with the Activity, then by default, the dates of the parent Activity are assumed to encompasse the sub-activity defined. Similarly, if no dates are provided for the parent Activity, then the dates provided by the Scheme_entry will prevail. Partial dates (e.g. if only a planned start date were provided), work in a similar manner with the defaults being set by those dates higher in the chain.
NOTE It is assumed that the lower order date ranges will be within the range of those specified higher in the chain, although there is no specific mechanism in place to ensure this in the model. This may be the subject of a rule for this DEX.
Each Activity may be characterized by an Approval_assignment. This can be achieved through the use of the assigning_approval template.
The presence of an Approval at the Activity level may indicate that the item requires a different authorization. Approvals at this stage of the model should be classified as a activity_approval_code (a sub-class of approval_code).
A specific Approval at this or lower levels in the chain, shall take precedence over corresponding ones higher up (for example, at the work package or Work_order level). The status of such an Approval may be a rejection (dis-approval), approved or unknown.
By default, it is assumed that when no explicit Approval is provided for an Activity or sub-activity, that the approval is inherited from the Approval of the next parent in the chain, be it a parent Activity, Scheme_entry, Scheme or Work_order level. It is assumed that the Approval of the work order and work package shall subsume all the relevant work items specified within the work package, unless explicitly stated otherwise. This may be the subject of a rule for this DEX.
NOTE There is no mechanism within this DEX to ensure the consistency of approvals at the different levels within the work package definition. This may be the subject of a rule for this DEX or a requirement for enahncement at a later date.
Each Activity may be related to one or more required Resource_item. This can be achieved through use of the assigning_required_resource_item template. The template is provided below.
NOTE Each of the main entities is available as a reference parameter making each one able to be refered to by another template if required.
NOTE The items referable by the select type lists emphasis those that are applicable for DEX4. That is, those greyed out are not in scope for DEX4 at present.
The shortened version of this template is shown below. It shows the two most likely used, but optional characterizations.
Resource_items such as consumables, tools, personnel and other equipment (e.g. parts) may be associated with an Activity and classified accordingly, (e.g. as a consumable or otherwise). Each Resource_item will require a separate assignment and hence additional use of the template provided.
Each Required_resource_assignment may be classified in terms of the role required (e.g. as a type of Required_resource_assignment_role or sub-class). The following initial sub-classes are provided below and are described further in capability C052: representing_resource.
Each Resource_item may be classified in terms of the type of resource (e.g. as a Material_resource_item or otherwise). The types of classification are provided below and more extensively in capability C052: representing_resource.
Other types of information can be assigned to each of the main entities (Required_resource_assignment, Required_resource_by_resource_item, and Resource_item), where required and these are outlined in the figure below. This optional template usage is described in capability C052: representing_resource.
Resource_item objects may be related to other Resource_items or to other items.
Relationships between Resource_items are defined using either a Resource_item_relationship or the subtype Resource_group_relationship with the role being defined by classification, rather than by means of an explicit attribute. There are no constraints on the network of relationships. The subtype of this relationship Resource_group_relationship, which covers relationships such as "a tool box contains a mallet" or "a compressor provides compressed air". While the former relation allows for Resource_items to be related on a 1:1 basis, the latter (group) allows for an optional quantity to be specified in conjunction with the related resource_item.
Both relationships imply that all the particular resources identified could be managed as a single unit. For example, by identifying a single Resource_item such as a toolbox or repair kit, the contents may be exposed through a decomposition relationship, if required, or the kit can be treated as a single item.
There are several classifications of the Resource_group_relationship, which may be used to characterize the context in which the Resource_items are related. For example;
NOTE It should be noted that the first three above are designed to be extended and specialised further.
EXAMPLE The class "Contains" (urn:plcs:rdl:std:Contains) is an example sub-class of a "Physical_resource_grouping" (urn:plcs:rdl:std:Physical_resource_grouping) which is a type of Resource_group_relationship where the related and relating Resource_items are physical objects. This classification implies that the relating resource item contains the related resource item. If a quantity is provided then this reflects the number of related resource items present. E.g. The toolbox contains (15) spanner(s).
See capability C052: representing_resource for further information.
Resource_items may also be the subject of Resource_item_assignment, where the resource is assigned to one of;
The classification of the assignment (to provide the role) should reflect the selected Resource_item and the item being related (above). Sub-classifications from the assignment currently include the following;
NOTE Both Resource_item_assignment and Resource_item_relationship may be further characterized (see capability C052: representing_resource).
Resources provided with no indication of quantity or amount are treated as single items or single unit quantities by default, unless otherwise specified.
Resources assigned to the Activity which is assigned to the Scheme_entry are, by default assumed to be required for all decomposed sub-activities defined, unless specified otherwise.
Resources provided at a parent Activity level are assumed to be resources required by all decomposed sub-activities defined, unless specified otherwise.
To avoid over (or under) estimations of resources required, it is advised that resources be assigned using a bottom-up approach. That is, resources should be assigned to the lowest level activities first.
If the same resources are required by all sub-activities defined within the decomposition of the parent, then these may be candidates for inclusion at the higher level.
In the complex situation where there are multiple hierarchies of activities, the distribution of these resources at the lower decompositions must either be made explicitly, or they are, by default, expected to be equally distributed among each sub-decomposition. This may lead to a situation where there are more sub-decompositions than there are Resource_items to go around.
To avoid this and the implication of an impossible situation, the sub-decompositions are required to explicitly state their own required resources, where relevant. The impact of this is that those resources assigned at the next higher Activity level are purely a cumulative measure of the quantity required for the whole task.
From the perspective of downstream reporting on activities (out of scope for DEX4), it is prefereable that the resources be explicitly identified through the activities that use them rather than at a higher level where their usage is more implicit. Where both are specified, the parent provides a guide to the requirements below.
NOTE The summation of resources assigned at lower levels of decomposition take precedence over quantities of the same resource item assigned to the parent.
NOTE There is no mechanism currently within this DEX to ensure any consistency between the quantification of resources at a parent node and the sum of those assigned at child nodes. The possibililty of this is the subject of an issue and possible rules or extensions to this DEX.
Each item of work, represented by a Scheme_entry, may be broken down or decomposed into a number of sub-activities.
Hence, in addition to the top-level Activity which equates with the Scheme_entry, there may be a one or more sub-activities defined using an instance of activity_relationship classified as an activity_decomposition.
Where these sub-activities need to be ordered (sequenced), another activity_relationship should be provided between them, classified as activity_sequence.
NOTE There is only a single Scheme_entry to the top level Activity and this should be considered the entry point to the Activity defined.
NOTE The Activity to be decomposed should be specified as the activity_relationship.relating_method, while the sub-activities shall be activity_relationship.related_method.
NOTE The first in the sequence should be specified as the activity_relationship.relating_method.
The definition of an Activity has been harmonized with the mechanism defined for defining tasks (see DEX 3), to enable a consistent, interoperable approach. This effectively treats the definition as a Document attached to the Activity identified.
The identification of the Activity shall be provided through the use of an Identification_assignment classified as a activity_identification_code (or sub-class thereof).
The type of Activity should be provided through the use of a Classification_assignment . The types of classification shall be an activity_usage (or a sub-class thereof).
The role of the Document_assignment entity shall be provided through the use of the class descriptor (see Assigning_descriptor).
The description attribute of the assigned Document entity instance shall provide the description of the Activity being defined.
The role of the Document assigned shall be provided through the use of a Classification_assignment where the external_class.name shall be activity_definition.
The definition of an example Activity is provided below.
A typical work item is a generic method which provides a general solution for the Activity of which it is the chosen_method. The solution is defined as an Activity_method. It is not necessary to specify typical methods, however, they may be declared as 'typical' so that they might be re-used, possibly as part of a library.
Alternatively, they may represent typical tasks defined in a library, but are used in a manner which was not defined in the library. For example, the method may be used to identify a solution to an issue raised against a different product than the library definition allowed for. This may be due to either an unforeseen set of maintenance requirements, un-predicted failures, or because of the asset has been configured in a manner not consistent with the design.
This DEX does not define tasks, nor prescribe how they are stored within such a library, or how such a library should operate. However, where such libraries exist, it is sometimes necessary to augment the contents with locally defined ad-hoc tasks, enhancements to a library task, or the re-use of a library task for an alternative purpose.
Before describing these scenarios any further, we need to define the representation of an Activity_method.
The identification of a typical Activity is represented by an instance of Activity_method which shall cary an Identification_assignment classified as a "Activity_method_identification_code" (urn:plcs:rdl:std:Activity_method_identification_code).
An Activity_method can be refered to as a both a "typical" (the activity aspect) and as a "procedure"(the method aspect). The classification should hence be provided through the use of a Classification_assignment where the External_class is a type of "Typical_procedure" (urn:plcs:rdl:std:Typical_procedure) (or sub-class thereof).
The types of "Typical_procedure" (urn:plcs:rdl:std:Typical_procedure) currently defined include the following;
The description of an Activity_method to be performed should be provided through the use of an assigned descriptor using the template assigning_descriptor defined in capability C095: assigning_descriptor. The result of this is an assigned Document whose description attribute is populated by the text of the procedure description.
A definition may not be provided depending upon whether the procedure identified is classified as a library definition ( "Typical_reference_procedure" (urn:plcs:rdl:std:Typical_reference_procedure)). The definition may be provided in addition to the reference if it is enhancing the library version or if it is to be used in preference of the library version ( "Typical_detailed_reference_procedure" (urn:plcs:rdl:std:Typical_detailed_reference_procedure)). This usage is described in a later section.
If the activity to be defined represents a typical activity, then the description of the activity should be referenced from the associated Activity_method. For an activity which has no assigned_document in the role of a descriptor, it is assumed that there will be a chosen_method where the assigned_descriptor will be found. This is the default scenario and makes no assumptions about the existence of a library.
If the activity to be defined represents a temporary (e.g. one-off) enhancement to an existing typical activity, then the description of the activity should be defined locally, and not with the Activity_method identified. The Activity_method in this scenario is purely for referencing purposes. An Activity_method found with no descriptor assigned indicates that the typical method is temporarily displaced by the descriptor found attached to the Activity referencing the Activity_method itself.
If the activity to be defined represents a change to a typical activity, then in addition to the local description of the Activity, the descriptor should also be referenced from an associated Activity_method. This will involve a second Document_assignment but the Document itself need not be duplicated. A descriptor found attached to both an Activity and a related Activity_method, indicates that the typical Activity_method has been replaced by the one referenced.
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.
This section describes the manner in which the Product In Focus (PIF) is referred to within the current version of this DEX. It is not the role of this DEX, however, to represent the product (or design) as a whole, nor it's assembly, configuration or breakdown. For representation of these aspects, see DEX 8 for the realized product and/or DEX 1 for the design representation. This DEX makes the assumption, that these representations are already available to the receiving system and that this DEX only makes reference to applicable components within those representations already provided.
There are three key references which this DEX uses to refer to the product in focus:
NOTE This list is not definative in that in some situations not all three will be available. For example, in some systems only the first two items may be known, in others it may be only the first and last. However, in all situations, the first item will always be required.
Given that the asset is a physical product, it's identification ís represented by a Product_as_individual. This is described in the capability C045: representing_product_as_individual. All three references above may be represented as Product_as_individuals. Other types of supporting types of identification such as the manufacturer, the Unique Identification (UID), and other codes can be used in addition.
These three types of references occur in different areas of the DEX as outlined below.
The top-level asset is assumed to be the main product for which the work order, directive and life cycle opportunity have been devised. The reference to the asset itself is represented by an instance of Product_as_individual.
EXAMPLE Ship, aircraft, vehicle, bike or other complex product.
The top-level asset should be assigned to the highest level within the DEX, which should be the Work_order directive, represented by an instance of Directed_activity. The same asset shall be refered to by the life cycle opportunity to do work.
The next higher level equipment refers to the equipment within which the end item is found or can be located. The reference to the equipment, which may be represented by a Product_as_individual within an assembly, configuration or it's equivalant within a breakdown, is assumed to be related to the top-level asset refered to above. It focuses attention to the area of the asset which requires attention.
EXAMPLE A fuel supply system, electrical power supply system or cooling system.
EXAMPLE A bike's braking system, drive-train or suspension.
The item representing the next higher assembly that is refered to may be one of several types. The most direct and likely used will be identified through another combination of Product_as_realized and Product_as_individual instances. The Product_as_individual in this case would represent the next higher assembly item within which the end item can be found.
Alternatively, the next higher assembly item may be referenced through the identification of a Product_configuration, a Breakdown_element_definition (or a subtype thereof, such as System_element_definition, Physical_element_definition, Functional_element_definition, Zone_element_definition), or an Attachment_slot.
The use of references such as these (above) occurs where different systems in the supply chain use different representations of the asset because, for example, they frequently do not need a full product model of the asssembly, configuration or breakdown. In these cases, the reference to the actual Product_as_individual representing the next higher assembly is not explicitly required.
However, it may be derived indirectly, given the availability of a full product model, where each type of above reference may, if required, be traced through the model to the actual Product_as_individual. This is beyond the current DEX4 and it is assumed that the recieving system has (through other exchanges or configuration) the relevant product structure to trace the item. If not then a D008: product_as_individual exchange will be necessary to obtain this information.
More than one identifier of the equipment may be provided. For example, a Physical_element_definition, a System_element_definition and a Zone_element_definition may be provided. Each definition may be realized by the actual equipment represented by a Product_as_individual. However, it is not the responsibility of this DEX to ensure that such references are consistent with the actual equipment being identified.
NOTE This DEX will not provide the relationship between the equipment and the top-level asset. See DEX 8 and/or DEX 1 for such information.
NOTE This DEX does not record or represent the relationship between the top-level asset and the equipment. The asset - equipment relationship may or may not reflect the actual position of the equipment within the asset, depending upon the type of breakdown being used. Thus, it is not meant to reflect the actual physical breakdown of the asset. For example, it may only reflect a work breakdown structure rather than the actual physical breakdown or assembly.
An attachment slot can either be occupied or un-occupied. Frequently an atttachment_slot on the asset may be able to fit multiple types of alternate parts or equipment. The part fitted into the Attachment_slot may or may not be a product with it's own history which can itself, be treated as an asset. The Attachment_slot may itself be the target of maintenance activity, as well as, or instead of the part which occupies it.
EXAMPLE A mounting under an aircraft wing for attaching weapon systems.
EXAMPLE A laptop computer PCMIA slot for wireless communication card, tv card or other added functionality.
EXAMPLE A laptop computer USB slot for similar or (now) wider functionality, such as, pointing_device,
EXAMPLE A bicycle's attachment slot for holding a bike-pump, lights for illumination or even for holding a bicycle lock.
The end item, for the purposes of this DEX, is the item which requires maintenance, removal or replacement. It may be a Product_as_individual, a Breakdown_element_definition (or subtype thereof), an Attachment_slot or the Product_in_attachment_slot.
An overview of the usage of the top-level asset, next higher level assembly / equipment and end item is presented below.
Given the contexts provided above, each Product_as_individual may be identified within a particular context, rather than a direct reference. The next few sections describe these typical types of contexts and how references can be made within the contexts defined.
The following contexts can be used to refer to the Product_as_individual:
Referencing a product as individual by serial number
The Product_as_individual can be identified by using the code assigned to it, normally a serial number. This is described in this capability. The identification code is represented by an instance of Identification_assignment which is classified as "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code) or a sub class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code). If the identification code represents a serial number, then the Identification_assignment is classified as a "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) which is a sub class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code). If appropriate, sub classes of "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) may be used, including:
The Product_as_individual can be related to a Part through the instantiation of Product_design_to_individual. A Part is identified by a part number which is assigned to the Part by an instance of Identification_assignment which is classified as "Part_identification_code" (urn:plcs:rdl:std:Part_identification_code).
NOTE The relationship back to the design is not essential for unambiguous identification of a Product_as_individual, but is helpful.
An EXPRESS-G diagram showing how the product as individual is related to a part.
Additional context information about the identification, such as the organization that provided the identification and hence the context in which it is unique is provided by assigning the organization to the identification (See C001: assigning_identifiers for further details on identification).
NOTE It is assumed that the serial number assigned as an identification to the Product_as_individual does not reflect any versioning of the product. If a modification is made to Product_as_individual then a new version is created and identified as described in the next section.
Referencing a modified product as individual
A Product_as_realized is essentially a version of an actual product. The original, as-built, unmodified product being represented by one instance of Product_as_realized; and subsequent modifications to the product resulting in further instances of Product_as_realized. However, the Product_as_individual remains the same.
The instance of Product_as_individual shall be identified by an instance of Identification_assignment which is classified as "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code) or a sub class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code). If the identification code represents a serial number, then the Identification_assignment is classified as a "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) which is a sub class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code). Where appropriate, sub classes of "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) may be used as described above.
The instance of Product_as_realized is identified by an instance of Identification_assignment that is classified as a "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code).
Each Product_as_realized must refer back to the Product_as_individual of which it is a version.
The Product_as_realized can be related to a Part_version through the instantiation of Product_design_version_to_individual. A Part_version is identified by a part number which is assigned to the Part_version by an instance of Identification_assignment that is classified as a "Version_identification_code" (urn:plcs:rdl:std:Version_identification_code).
Additional context information about the identification, such as the organization that provided the identification and hence the context in which it is unique is provided by assigning the organization to the identification (See C001: assigning_identifiers for further details on identification).
Referencing a product as planned
A Product_as_planned represents a revision of an individual artefact that has yet to be made.
An instance of Product_as_planned may be identified by an instance of Identification_assignment which is classified as "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code) or a sub class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code). If the identification code represents a serial number, then the Identification_assignment is classified as a "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) which is a sub class of "Product_as_individual_identification_code" (urn:plcs:rdl:std:Product_as_individual_identification_code). If appropriate, sub classes of "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) may be used, including:
A Product_as_planned can be related to the Product_as_realized that reifies that planned artefact by instantiation of a Product_planned_to_realized relationship.
Referencing a product as individual in a configuration
Where the Product_as_individual is part of an assembly, which has different configuration options the Product_as_individual can be identified in the context of a configuration of the assembly. This is achieved by identifying the relevant Item_design_association entity and Product_configuration entity.
The details and example for referencing a Product_as_individual in a configuration is provided within capability referencing_product_as_individual_configurationError C1: Capability referencing_product_as_individual_configuration not in dex_index.xml
.
Referencing a product as individual in the context of a breakdown
Where a Product_as_individual is linked to an element in a product breakdown structure (see C004: representing_breakdown_structure) by a Breakdown_element or its subtypes and a Breakdown_element_realization or in the case of a zonal breakdown, a In_zone relationship, then the Product_as_individual can be identified in the context of the breakdown.
In order to uniquely identify a Breakdown_element the following information is required
The Breakdown_context provides a link between the Breakdown_element and the product for which theBreakdown has been defined.
NOTE The breakdown context is optional and may be left out if the Breakdown_element is uniquely identified by its id and version.
The parent-child relationships involving different Breakdown_elements is achieved through the corresponding (via Breakdown_element_version) Breakdown_element_definitions which are related together by instances of Breakdown_element_usage. However, it is not the role of this DEX to exchange the structure of a Breakdown.
In order to reference a Breakdown_element as the product in focus the following reference data shall be applied:
The details and example for referencing a Product_as_individual as part of a Breakdown is provided within capability referencing_product_breakdown_elementError C1: Capability referencing_product_breakdown_element not in dex_index.xml
.
Referencing a product as individual in an assembly
Where the Product_as_individual is part of assembly, it is necessary to be able to record the serial number of its parent in the assembly structure. This can be achieved through the entity Next_assembly_usage.
The details and example for referencing a Product_as_individual as part of an assembly is provided within capability representing_product_as_realized_assemblyError C1: Capability representing_product_as_realized_assembly not in dex_index.xml
.
Referencing a product as individual in an assembly by slot
If attachment slots are used (entity Attachment_slot_as_realized and described in C086: representing_slots), it may also be useful to record the attachment slot to which the Product_as_realized was fitted.
The details and example of referencing a Product_as_individual in an assembly by Attachment_slot is provided within capability C045: representing_product_as_individual.
Identification of Parts treated as Resource Items
Resource_items may refer to an instance of design e.g. a Part, or an actual individual part - i.e. a Product_as_individual.
The representation of a Part is documented within the capability C002: representing_parts and can be identified by a part number. The part number is represented by an identifier assigned by an Identification_assignment to the Part. The assignment is classified as a "Part_identification_code" (urn:plcs:rdl:std:Part_identification_code). This is provided by the capability C001: assigning_identifiers and the C001: assigning_identifiers template.
Each Product_as_individual should maintain a link to the design - of which it is an occurrence. This link is provided by an instance of Product_design_to_individual which relates a Part to a Product_as_individual.
As discussed already, the Product_as_individual is identifiable through a "Serial_identification_code" (urn:plcs:rdl:std:Serial_identification_code) (see above), care should be taken to ensure that it is of the same design as the part being replaced.
The C001: assigning_identifiers template can also be used to provide additional name identifiers such as "Part_name" (urn:plcs:rdl:std:Part_name), "Assembly_manufacturers_part_type_name" (urn:plcs:rdl:std:Assembly_manufacturers_part_type_name), "OEM_part_type_name" (urn:plcs:rdl:std:OEM_part_type_name), "User_part_type_name" (urn:plcs:rdl:std:User_part_type_name) etc., when relevant.
Using the template assigning_code described within C093: assigning_codes, allows the specification of other code identifiers such as "NSN_code" (urn:plcs:rdl:std:NSN_code).
By maintaining the link between the individual product and the design, it is possible to equate resource items that may only
be specified by part number to the actual end item attached to the asset. Likewise, it is possible to identify the product
design from the actual individual. With this information changes to asset, equipment, end items and configuration can be monitored
by noting changes to the serial numbers of the parts as they are replaced with new or refurbished stock, while ensuring the
part numbers are correct. Allowable alternate and/or substitute parts may also be allowed by the design configuration, or
from those identified with the same NSN code. Where a modification to the design is authorized by redesign or concession,
then there will be a change of part numbers and alternates. These are described in greater depth within the capability C002: representing_parts and referencing_product_as_individualError C1: Capability referencing_product_as_individual not in dex_index.xml
.
An EXPRESS-G diagram showing how the part refered to as a resource item is identified from an activity is shown below.
The work item Activity is associated with the target element through an Applied_activity_assignment. The representation of the subject of the work item is achieved using Capabilities referencing_product_breakdown_elementError C1: Capability referencing_product_breakdown_element not in dex_index.xml
, referencing_part_or_slotError C1: Capability referencing_part_or_slot not in dex_index.xml
or referencing_product_as_individualError C1: Capability referencing_product_as_individual not in dex_index.xml
.
A variance may record the case where the Product or Activity varies from the original intent. It allows for the authorization of the continued use, possibly with some restrictions, of the Product or Activity.
For most complex assets a maintenance schedule is designed alongside the product, such that the schedule may apply to many occurrences of the product in use. A scheduler adds Activitys when due according to actual circumstances and level of use etc., and the result may be communicated by a DEX4 exchange file. These Activitys, are in general typical ones, which are normally designed for a particular part or set of parts and resources (tools, personell, spares etc..), which are selected based upon the expected (predicted) level of maintenance required at that stage of the product's life cycle. When the product is no longer operating within the design envelope (i.e. a change to the configuration, operating limits or defined properties), then the maintenance tasks may need to adapt accordingly.
From a DEX4 perspective, recording variances of the Product and or Activitys is important since it may affect whether maintenance is;
Additionally, maintenance tasks may also become untenable when the resources required to carry out the procedures are not available (e.g. not all spares, tools, repair kits etc., may have been requisitioned before the ship leaves port). Still, others may become applicable depending upon the variance of the Product which would otherwise not be used.
Recording the variance from design, whether it be against a product or activity or both can be recorde using this DEX. It may also be relevant to record the cause and effect relationship between these two types of records where applicable, such that the continued use of one is not inadvertantly done so after the other has reverted to a non-variance state. This condition, evaluation and consequence arrangement can be represented through the C048: representing_condition_evaluated capability. However, this is not within the current scope of this DEX.
It is not the purpose of this DEX to describe or prescribe how maintenance tasks are defined (see DEX3), versioned or altered over time, except that an occurrence of a maintenance task may differ from that originally defined. Where this occurs and the occurrence represents a modification of the task from it's original design, then the activity should be the subject of a concession. In this sense, the maintenance Activity, can itself be treated as a Product.
Any variance of the target Product and or Activity from its design version can be represented by associating a Approval_assignment with an appropriate classifiction_assignment. This classification assignment indicates that the Approval_assignment / Approval is a type of variance. One such Classification is "Concession" (urn:plcs:rdl:std:Concession). Documents, Conditions and Justifications are then associated with the Approval as required.
Concessions are described within capability C046: representing_variance and able to be represented using the template assigning_concession. A shorthand notation of the template's usage is illustrated in Figure 42.
The basic concession records;
In addition, it is possible to assign:
to the approval representing the concession. These and other details are provided in the capability C046: representing_variance and able to be represented using the template assigning_concession.
NOTE The above figure shows a Product_as_realized as the subject of the concession. It may equally be applied to an activity.
A concession is represented by an Approval that is assigned (using Approval_assignment) to the subject of the concession. Typically the subject is a Product_as_realized or a planned activity (Activity). The Approval and Approval_assignment are classified as "Concession" (urn:plcs:rdl:std:Concession) (Classification and reference data is described in C010: assigning_reference_data). The Approval representing the concession will have a status associated with it indicating whether the concession has been approved or not. See C019: assigning_approvals for details on assigning approvals. The possible approval status are represented by the following classes stored as reference data:
The underlying reasons for the concession or waiver being granted may be based on performance measurements made on the product or may be an observed state of the product. These reasons are represented by a Justification that is assigned to the Approval by a Justification_assignment. The Justification_assignment is classified as a "Concession_justification" (urn:plcs:rdl:std:Concession_justification). The reasons for the waiver, such as the observed state or performance measure are identified by assigning them to the Justification. This is achieved by the use of a Justification_support_assignment. This assignment shall be classified as a "Concession_justification" (urn:plcs:rdl:std:Concession_justification).
The basic template for assigning justifications which can represent the scenario above can be found in Error T7: assigning_supported_justification does not exist in capability: representing_variance
assigning_supported_justification. A shorthand notation of how this template can be applied to that above, representing the concession (assigning_concession) is illustrated in below in Figure 43.
Within the template a description of the justification is represented through the assigning_descriptor template. This template assigns a Document classified as a "Descriptor" (urn:plcs:rdl:std:Descriptor), to the Justification. The document holds the text in the description attribute, while the Document_assignment is classified as a "Documented_justification" (urn:plcs:rdl:std:Documented_justification). Details of this are provided in the C046: representing_variance.
In addition to or an alternative to using Justification the reasons for the concession can also be recorded in a Document which is assigned to the Approval representing the concession by use of the template assigning_document and is an optional characterization of the assigning_concession template illustrated above. The assignment of the document in this case shall be of type "Documented_justification" (urn:plcs:rdl:std:Documented_justification) to distinguish it from other documents.
Optionally a Justification can be classified by using the template assigning_reference_data to assign a class to a Justification to identify the type of justification. The classification shall be a "Justification_type_code" (urn:plcs:rdl:std:Justification_type_code) or other suitable sub-class, such as "Concession_justification" (urn:plcs:rdl:std:Concession_justification) or "Cost_justification" (urn:plcs:rdl:std:Cost_justification).
Optionally, a Justification can be identified through the assignment of an identifier using Identification_assignment which may be specified through the template assigning_identification_with_no_organization described within the capability C001: assigning_identifiers.
The Identification_assignment of the Justification shall be classified as a type of "Justification_identification_code" (urn:plcs:rdl:std:Justification_identification_code) or a suitable sub-class thereof.
Other optional characterizations are described in the capability C046: representing_variance.
The above figure can be expanded to show the instantiation parameters required, as shown below. This view gives an indication of how the templates are related together, but the details of the templates are available from the C046: representing_variance capability.
Concessions may be justified by an identified failure mode. This is represented by a Justification_support_assignment relating the Justification to a State_definition representing the defined failure mode in e.g. a FMECA (Failure Modes and Criticality and Effects Analysis) See D002: fault_states for further details.
In many cases, the concession will be granted with an associated restriction for use. For example, a part (B) should have a 1mm hole in it. The operator made an error and a 1.1 mm hole is the result. This is noticed and a concession is raised to check whether this can be used. The concession is approved, however with the limitation that it can only be assembled into an aircraft that will not fly in conditions above 25 degrees C.
The restriction is represented either by Document and/or by using Conditions.
When a document is used to record the condition under which the concession is given, the document (Document) is assigned to the Approval representing the concession by a Document_assignment which is classified as a "Documented_condition" (urn:plcs:rdl:std:Documented_condition) to distinguish it from others. Details of representing documents is provided in C005: representing_documents.
When the condition under which the concession is given is to be made explicit, a Condition is assigned to the Approval representing the concession by a Condition_assignment. The Condition_assignment is classified as a "Concession_condition" (urn:plcs:rdl:std:Concession_condition). The inputs to the condition are represented by Condition_parameter. The use of condition is described in C026: representing_condition.
In other words, the Condition is used to represent the limitations, which if met, mean that the concession is approved.
The expression "below the 25 degrees C" is represented as the description attribute of a Document attached to an instance of Condition. I.e. in a non computer interpretable form. This is achieved through the assigning_descriptor template. This template assigns a Document classified as a "Descriptor" (urn:plcs:rdl:std:Descriptor), to the Condition. The document holds the text in the description attribute, while the Document_assignment is classified as a "Documented_condition" (urn:plcs:rdl:std:Documented_condition).
The basic template for Error T7: assigning_condition does not exist in capability: representing_variance
assigning_condition can be used in conjunction with assigning_concession as shown in the arrangement illustrated in Figure 45 below, to affect the required functionality of conditional concessions.
Optionally a Condition can be classified by using the template assigning_reference_data to assign a class to a Condition to identify the type of condition. The classification shall be a "Condition_type_code" (urn:plcs:rdl:std:Condition_type_code) or other suitable sub-class, such as "Concession_condition" (urn:plcs:rdl:std:Concession_condition).
Optionally, a Condition can be identified through the assignment of an identifier using Identification_assignment which may be specified through the template assigning_identification_with_no_organization described within the capability C001: assigning_identifiers.
The Identification_assignment of the Condition shall be classified as a type of "Condition_identification_code" (urn:plcs:rdl:std:Condition_identification_code) or a suitable sub-class thereof.
Other optional characterizations are described in the capability C046: representing_variance.
Figure 45 can be expanded to show the instantiation parameters required, as shown below. This view gives an indication of how the templates are related together.
The templates for assigning_concession, Error T7: assigning_supported_justification does not exist in capability: representing_variance
assigning_supported_justification and Error T7: assigning_condition does not exist in capability: representing_variance
assigning_conditioncan all be used together to generate justified, cnditional concessions when relevant, from the templates already discussed
above.
Given the complexity of the PLCS model for this area, a skeletal roadmap of DEX 4 presented below may provide a degree of navigation. It only shows the main connectivity between the major concepts in an EXPRESS-G-like manner. However, this figure has only selected parts of the model and does not show all relationships.
NOTE The above figure is not meant to provide a coding path for implementors and is not complete.
This figure provides the framework for the basic configuration presented Figure 7 in the opening sections of this Dex.
