1 Scope

The OPC UA for Machinery specification contains various building blocks for Machinery that allow to address use cases across different types of machines and components of machines defined in various companion specifications.

For the general scope of the OPC UA for Machinery specification see OPC 40001-1.

This part contains a building block for

Job Management

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

http://www.opcfoundation.org/documents/10000-1/

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

http://www.opcfoundation.org/documents/10000-3/

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

http://www.opcfoundation.org/documents/10000-5/

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

http://www.opcfoundation.org/documents/10000-6/

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

http://www.opcfoundation.org/documents/10000-7/

OPC 40001-1, OPC UA for Machinery - Part 1: Basic Building Blocks

http://www.opcfoundation.org/documents/40001-1/

OPC 10031-4, OPC UA for ISA-95 – Part 4: Job Control

http://www.opcfoundation.org/documents/10031-4/

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling, OPC 40001-1 and OPC 10031-4 are understood in this specification. This specification will use these concepts to describe the Machinery – Job Management Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-5, OPC 10000-7, OPC 40001-1, OPC 10031-4 as well as the following apply.

Note that OPC UA terms and terms defined in this specification are italicized in the specification.

3.2 OPC UA for Machinery – Job Management terms

3.2.1

job order

unit of scheduled work that is dispatched for execution (IEC 62264-3:2016(en))

Note: A job order is the concrete implementation of a set of information that a machine needs to execute a task. This information can be composed of one or more programs or recipes, or it can consist only of metadata and parameters (production-specific) or of all of these. Several job orders can be running at the same time.

3.2.2

run

A completed execution or completed subset of the execution carried out according to the data provided with the job order.

3.2.3

Item

an object produced as one quantity unit

Note: If pieces are produced, the quantity unit is always one piece. If no pieces are produced (e.g., kg or m), the quantity unit of an item can be determined by the planned quantity per run.

Examples:

15 pieces produced in 3 runs (5 pieces per run) -> quantity unit is one piece, 15 items produced

5,6kg produced in one run -> quantity unit is 5,6kg, 1 item produced

20m produced in two runs (10m per run) -> quantity unit is 10m, 2 items produced

3.3 Abbreviated terms

3.4 Conventions used in this document

For conventions used in this document see OPC 40001-1.

4 General information to Machinery and OPC UA

For general information to Machinery and OPC UA see OPC 40001-1.

5 Use cases

The user would like to provide job orders to a MachineryItem to get executed.

The user would like to control job orders by updating the job order, setting the job order to get executed or revoke the execution, pause and resume the execution, and abort or stop the executing.

The user would like to get information about the state of execution, retrieve intermediate results and the end result of the job order execution.

The user would like to delete the job order results from the MachineryItem after execution and receiving the job order.

6 Machinery Job Management Information Model overview

6.1 Overview

This chapter gives an overview over the job management information model. In 6.2, the ObjectTypes for managing job orders are described. 0 describes the integration into a MachineryItem. In 6.4, the mechanism for defining the order for the execution of job orders is defined, and in 6.5 the concept of predefined parameters for the description of job orders is introduced.

6.2 JobManagementType

In Figure 1 an overview of the JobManagementType is given. It is formally defined in 8.1. The JobOrderControl Object of 2:ISA95JobOrderReceiverObjectType provides functionality to add and control job orders to a MachineryItem. It also provides information about all job orders currently managed by the MachineryItem (in the 2:JobOrderList). It contains the description of a StateMachine that is applied to the job orders managed in the 2:JobOrderList (not shown in the diagram) that can be specialized and restricted. All job orders managed by the JobOrderControl support the same, potentially specialized StateMachine. Details of the 2:ISA95JobOrderReceiverObjectType are defined in OPC 10031-4.

Once a job order starts to be executed by the MachineryItem, it becomes available in the JobOrderResults Object to provide intermediate results or the final results of the job order execution. During that phase, the job orders can still be controlled by the JobOrderControl Object. The JobOrderResults Object is of 2:ISAJobResponseProviderObjectType and provides different mechanisms (Method, Event, or Variable) to expose the results (see OPC 10031-4 for details). Once the Client has received the end results, it can remove the results from the MachineryItem, and thereby also remove the meta data of the job order managed by the JobOrderControl Object.

6.3 Integration into a MachineryItem

In Figure 2 an example is shown, how the job management can be integrated into a MachineryItem. The building block, using its 0:DefaultInstanceBrowseName JobManagement, is added as AddIn into the 3:MachineryBuildingBlocks Object. In addition, it is referenced by some domain-specific organization.

Note that a MachineryItem may also add several job management instances in order to support different specialized StateMachines for the job orders. In this case, the 2:DefaultInstanceBrowseName should only be used once.

6.4 Order of Execution of Job orders

MachineryItems may execute several job orders in parallel or just one job order at a time. Depending on the application, the order of the execution may be defined by different mechanisms. In some cases, the order is determined by a global system and provided with the job order meta data, in other cases, the operator of a machine might choose of a list of job orders.

The general rules on how the execution of job orders is determined:

Job orders can only be executed if they are in the corresponding state (see OPC 10031-4). Applications may choose to only set one job order into that state explicitly to start a job order (e.g. by the operator of the MachineryItem).

If the job order is in the state to be executed, and more than one job order is in that state, the 2:StartTime of 2:ISA95JobOrderDataType indicates the order the job orders shall be executed. The earliest time indicates that the job order shall be started next. Applications may choose to set the same 2:StartTime to several job orders in order to indicate that all those job orders could be executed next.

If there are several job orders having the same 2:StartTime, the 2:Priority of 2:ISA95JobOrderDataType indicates, which job order shall be executed next. The job order with the highest 2:Priority shall be executed next. Applications may choose not to set a priority or let several job orders have the same 2:Priority (and same 2:StartTime).

In case neither the 2:StartTime nor the 2:Priority indicate the order; it is application specific which job order starts next. Companion Specifications may define additional mechanisms.

The order of the job order execution shall be reflected in the 2:JobOrderList. That is, the array shall start with all executed job orders (in the order the execution started), followed by all job orders currently executed or interrupted (in the order the execution started), followed by the job orders that can start to be executed, followed by the job orders that currently cannot start to be executed.

The job orders that can be executed shall be ordered based on 2:StartTime and 2:Priority, also the job orders that currently cannot start to be executed. Note that the order of both is not necessarily absolute, i.e. several entries in the array may be on the same level but put into an arbitrary order and may not be started in the order of the array.

6.5 Predefined parameters for job management

In OPC 10031-4 the bare minimum of meta data is defined describing a job order and an extensibility mechanism is built into the data structures allowing to provide additional meta data. This specification uses the mechanism to define additional meta data in 7. Companion specifications may define additional meta data. Profiles defined in 10 or other companion specifications may require the presence of specific meta data.

7 Predefined Job-Order-Input and Job-Order-Response Information

7.1 Overview

ISA95 job control (OPC 10031-4) defines mechanisms to add job order information using the 2:ISA95JobOrderDataType and mechanisms getting the result or current status of the job order using the 2:ISA95JobResponseDataType. Both DataTypes define arrays of properties of a job order: general, personnel, equipment, physical assets, and material. The 2:ISA95JobOrderDataType uses the general properties to describe the job order and the other properties to define the requirements, whereas the 2:ISA95JobResponseDataType uses the general properties to describe the output and the other properties to provide the information what has been used.

This specification standardizes some of those parameters, which are application-specific from the view of OPC 10031-4.

7.2 Predefined JobOrderParameters and JobResponseData

In Table 1, predefined key-value pairs for 2:JobOrderParameters and 2:JobResponseData is provided. The table indicates, in which data structure the key-value pair is expected to be used. An “X” in “In” indicates it may be used in 2:JobOrderParameters an “X” in “Out” indicates it may be used in 2:JobResponseData.

Note: PRI (planned run time per item) as defined in ISO22400 equals PlannedTimePerRun divided by PlannedQuantityPerRun.

7.3 Personnel

This specification does not define any standardized entries for 2:PersonnelRequirements or 2:PersonnelActuals. However, the operators executing the job order may be returned in the 2:PersonnelActuals, where each entry represents one operator (in the ID of 2:ISA95PersonnelDataType). The optional fields may be used as defined in OPC 10031-4.

7.4 Equipment

This specification does not define any standardized entries for 2:EquipmentRequirements and 2:EquipmentActuals. However, the planned equipment may be provided in the 2:EquipmentRequirements, and the actual used in 2:EquipmentActuals.

If an equipment is a component of a MachineryItem modelled in the OPC UA Server, and the 4:AssetId is provided, the 4:AssetId shall be used as ID in the 2:ISA95EquipmentDataType.

If the equipment are components of a MachineryItem modelled in the OPC UA Server, and the 4:ComponentName is provided, it should be provided as additional entry in the 2:Properties array of the 2:ISA95EquipmentDataType, as specified in Table 2.

7.5 Physical Assets

This specification does not define any standardized entries for 2:PhysicalAssetRequirements and 2:PhysicalAssetActuals. However, the planned physical assets may be provided in the 2:PhysicalAssetRequirements, and the actual used in 2:PhysicalAssetActuals.

7.6 Material

For all Material provided, the optional 2:Quantity and 2:EngineeringUnits as well as the 2:MaterialDefinitionID shall be provided.

If the 2:MaterialDefinitionID and the Identification is provided, the ItemNumber of the Identification shall be identical to the 2:MaterialDefinitionID.

If the 2:MaterialLotID and the Identification is provided, the LotNumber shall be identical to the 2:MaterialLotID.

In Table 3, predefined key-value pairs for 2:MaterialRequirements and 2:MaterialActuals is provided. The table indicates, in which data structure the key-value pair is expected to be used.

8 OPC UA ObjectTypes

8.1 JobManagementType ObjectType Definition

The JobManagementType provides an AddIn for job management and is formally defined in Table 4.

The JobOrderControl Object provides functionality to add job orders and control them (pausing, aborting, etc.). It provides information about the currently managed job orders of the job management. It shall be used as defined in OPC 10031-4.

The JobOrderResults Object provides information about the current status about running job orders. It shall be used as defined in OPC 10031-4.

In case the JobOrderControl provides the 2:JobOrderList and the JobOrderResults provides the 2:JobOrderResponseList, the following rules apply.

For each entry in the 2:JobOrderResponseList shall be a corresponding entry in the 2:JobOrderList (having the same 2:JobOrderId).

For each entry of the 2:JobOrderList having a 2:State different than 2:AllowedToStart or 2:NotAllowedToStart (including substates), there shall be a corresponding entry in the 2:JobOrderResponseList (having the same 2:JobOrderId).

The child Nodes of the JobManagementType have additional Attribute values defined in Table 5.

9 OPC UA DataTypes

9.1 JobExecutionMode

This enumeration JobExecutionMode describes the execution mode of the machine for the job order. The enumeration is defined in Table 6.

Its representation in the AddressSpace is defined in Table 7.

9.2 JobResult

This enumeration JobResult describes the high-level result of an executed job order. The enumeration is defined in Table 8.

Its representation in the AddressSpace is defined in Table 9.

9.3 OutputInformationDataType

This structure contains identification information. The structure is defined in Table 10.

Its representation in the AddressSpace is defined in Table 11.

9.4 OutputInfoType

This OutputInfoType is a bitmask that defines the usage of a provided output. It is defined in Table 12.

Its representation in the AddressSpace is defined in Table 13.

9.5 BOMComponentInformationDataType

This structure contains information about a component of the bill of material. The structure is defined in Table 14.

Its representation in the AddressSpace is defined in Table 15.

9.6 BOMInformationDataType

This structure contains information about one item of the bill of material. The structure is defined in Table 16.

Its representation in the AddressSpace is defined in Table 17.

9.7 OutputPerformanceInfoDataType

This structure contains an individual performance information. The structure is defined in Table 18.

Its representation in the AddressSpace is defined in Table 19.

9.8 ProcessIrregularity

This enumeration ProcessIrregularity describes if a process irregularty took place. The enumeration is defined in Table 6.

Its representation in the AddressSpace is defined in Table 7.

10 Profiles and ConformanceUnits

10.1 Conformance Units

This chapter defines the corresponding Conformance Units for the OPC UA Information Model for Machinery – Job Management.

10.2 Profiles

10.2.1 Profile list

Table 23 lists all Profiles defined in this document and defines their URIs.

10.2.2 Server Facets

10.2.2.1 Overview

The following sections specify the Facets available for Servers that implement the Machinery – Job Management companion specification. Each section defines and describes a Facet or Profile.

10.2.2.2 Machinery Job Management Base Server Facet

Table 24 defines a Facet with the base functionality of job management. Note, that it does not include the eventing mechanism. This mechanism is already defined by 2:ISA-95 Job Order Status Events Server Facet.

10.2.3 Client Facets

10.2.3.1 Overview

This specification does not define any client facets or profiles. Note that OPC 10031-4 already defines client facets that can be used.

11 Namespaces

11.1 Namespace Metadata

Table 25 defines the namespace metadata for this document. The Object is used to provide version information for the namespace and an indication about static Nodes. Static Nodes are identical for all Attributes in all Servers, including the Value Attribute. See OPC 10000-5 for more details.

The information is provided as Object of type NamespaceMetadataType. This Object is a component of the Namespaces Object that is part of the Server Object. The NamespaceMetadataType ObjectType and its Properties are defined in OPC 10000-5.

The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.

Note: The IsNamespaceSubset Property is set to False as the UANodeSet XML file contains the complete Namespace. Servers only exposing a subset of the Namespace need to change the value to True.

11.2 Handling of OPC UA Namespaces

Namespaces are used by OPC UA to create unique identifiers across different naming authorities. The Attributes NodeId and BrowseName are identifiers. A Node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes may have the same BrowseName. They are used to build a browse path between two Nodes or to define a standard Property.

Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the EngineeringUnits Property. All NodeIds of Nodes not defined in this document shall not use the standard namespaces.

Table 26 provides a list of namespaces that may be used in a Machinery – Job Management OPC UA Server.

Table 27 provides a list of namespaces and their indices used for BrowseNames in this document. The default namespace of this document is not listed since all BrowseNames without prefix use this default namespace.

12 (normative) Machinery – Job Management Namespace and mappings

12.1 NodeSet and supplementary files for Machinery – Job Management Information Model

The Machinery – Job Management Information Model is identified by the following URI:

http://opcfoundation.org/UA/Machinery/Jobs/

Documentation for the NamespaceUri can be found here.

The NodeSet associated with this version of specification can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/Machinery/Jobs/&v=1.0.1&i=1

The NodeSet associated with the latest version of the specification can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/Machinery/Jobs/&i=1

Supplementary files for the Machinery – Job Management Information Model can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/Machinery/Jobs/&v=1.0.1&i=2

The files associated with the latest version of the specification can be found here:

https://reference.opcfoundation.org/nodesets/?u=http://opcfoundation.org/UA/Machinery/Jobs/&i=2

___________

13 (informative)Examples

13.1 Overview

This annex gives examples on how the model can be used.

13.2 Example of a job order producing glass

In Table 28, an example JobResponseData is provided.

13.3 Example of a job breaking a tree down into a shelf floor, table legs and chips

First, the job is sent from the MES system to the woodworking machine. This can be either done by calling the 2:Store or the 2:StoreAndStart Method on the 2:JobOrderReceiverObject defined in OPC 10031-4. In both cases, the job order information is transferred as instance of ISA95JobOrderDataType. An example of such a data structure is given in Table 29. In Figure 3, the planned job order is sketched. From a tree, 1 shelf floor and 4 table legs should be created. In addition a bag of chips is created.

After the job order is received, it needs to be in state “AllowedToStart” before it can be executed. In case of the 2:StoreAndStart Method, it is already in the state, otherwise the 2:Start Method needs to be called. Once it is in the “AllowedToStart” state, the woodworking machine is internally starting the job order once it is ready (and depending on priorities of other job orders which are “AllowedToStart”. As soon as the job order has started (state of the job order is “Running”), the machine can provide results of the execution of the job order. The job order may get interrupted, or even aborted. Or it completes by switching into the “Ended” state. In Table 30, the final job order results, provided in an instance of 2:ISA95JobResponseDataType, are shown.

Agreement of Use

COPYRIGHT RESTRICTIONS

This document is provided "as is" by the OPC Foundation and VDMA.

Right of use for this specification is restricted to this specification and does not grant rights of use for referred documents.

Right of use for this specification will be granted without cost.

This document may be distributed through computer systems, printed or copied as long as the content remains unchanged and the document is not modified.

OPC Foundation and VDMA do not guarantee usability for any purpose and shall not be made liable for any case using the content of this document.

The user of the document agrees to indemnify OPC Foundation and VDMA and their officers, directors and agents harmless from all demands, claims, actions, losses, damages (including damages from personal injuries), costs and expenses (including attorneys' fees) which are in any way related to activities associated with its use of content from this specification.

The document shall not be used in conjunction with company advertising, shall not be sold or licensed to any party.

The intellectual property and copyright is solely owned by the OPC Foundation and VDMA.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC or VDMA specifications may require use of an invention covered by patent rights. OPC Foundation or VDMA shall not be responsible for identifying patents for which a license may be required by any OPC or VDMA specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC or VDMA specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION NOR VDMA MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION NOR VDMA BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830.

COMPLIANCE

The combination of VDMA and OPC Foundation shall at all times be the sole entities that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials as specified within this document. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by VDMA or the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

TRADEMARKS

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable, or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of Germany.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.