1 Scope

This document defines the OPC UA companion specification for ISA-95 Job Orders, ISA-95 Job Responses, and access to queued, executing, and completed job order status and responses.

Version 2.0 of this specification has been updated with breaking changes; in that it is not compatible with version 1.0 of the specification. Thus, this specification defines a new namespace, allowing an older application to support both models if required.

2 Normative References

The following referenced documents are indispensable for the application of this standard. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

OPC 10000-1, OPC UA Specification – 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-4, OPC Unified Architecture - Part 4: Services

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

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 10000-16, OPC Unified Architecture - Part 16: State Machines

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

ISA-95 Part 3: ANSI/ISA-95.00.03-2013 (IEC 62264-3 Modified) Enterprise-Control System Integration - Part 3: Activity Models of Manufacturing Operations Management

https://www.isa.org/products/ansi-isa-95-00-03-2013-enterprise-control-system-i

3 Terms, abbreviated terms, and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling are understood in this specification. This specification will use these concepts to describe the ISA-95 object models. The concepts and terms used to describe the OPC UA Information models are defined in other parts and listed in the following sections. Note that OPC UA terms and terms defined in this standard are italicized in the specification.

For the purposes of this document, the terms and definitions given in OPC 10000-1 and OPC 10000-3 as well as the following apply.

3.2 OPC UA for ISA-95 Terms

3.2.1 Job Order Receiver

An OPC UA server that implements methods to receive Job Orders and processes the associated job orders.

3.2.2 Job Response Provider

An OPC UA server that implements methods to provide Job Responses and returns a Job Response to the method caller.

3.2.3 Job Response Receiver

An OPC UA server that implements methods to receive Job Responses and accepts an unsoliciated Job Response from the method caller.

3.3 Abbreviated terms

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

3.4.1.1 Node definitions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.4.2.2).

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and Other columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.4.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.4.1.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

References can be to any other Node.

3.4.1.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.4.1.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

3.4.2 NodeIds and BrowseNames

3.4.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this document, because they are not defined by this document but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in 8.2.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3.If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 93 provides a list of namespaces and their indexes as used in this document.

3.4.3 Common Attributes

3.4.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this document or if it is server-specific.

For all Nodes specified in this document, the Attributes named in Table 7 shall be set as specified in the table.

3.4.3.2 Objects

For all Objects specified in this document, the Attributes named in Table 8 shall be set as specified in the Table 8. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.3 Variables

For all Variables specified in this document, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.4 VariableTypes

For all VariableTypes specified in this document, the Attributes named in Table 10 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.5 Methods

For all Methods specified in this document, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 ISA-95 Overview

For OPC UA users that may not be familiar with ISA 95 Part 4 Job Orders the following section provides a brief overview of key elements of job order management.

4.1 Job Order

ISA 95 defines a Job Order as a request for a unit of work to be executed. Typically, these are the lowest level scheduled objects in a work schedule, as shown in Figure 1. In ISA 95 a Work Schedule defines all the activities to be accomplished to meet a production request (or production order). A Work Schedule is made up of one or more Work Requests, depending on how the work is to be split, such as one order for packaging of 1,000,000 bottles, to be executed as 4 separate work requests of 250,000 bottles each. Each Work Request is made up of one or more Job Orders which define the work to be done in a work center (such as a packaging line or production line).

Job Orders have a procedure or workflow that is followed, either automatically or manually. Typical Job Orders in serialization are packaging orders for specific products. The Job Order contains all the variable information about the job order, such as quantity to be packaged, various values to be printed on labels, and any options, such as inserts to be added or case packing options. Each Job Order identifies a Work Master to be used. Work Master is the ISA 95 term for the procedure that is to be followed. Examples of Work Masters include ISA 88 Master Recipes or ISA 95 Workflow Procedures.

Job Orders are often sent from Level 3 MES/MOM systems to batch execution systems, automation systems (PLCs and DCSs), or workflow systems for manual operations. An often-used implementation is to have an ERP or MES sent Job Orders to specific parts of production. In Figure 1, for example a production line is executing one set of Job Orders, a packaging line is executing another set, synchronized with the production line, a palletizing line, synchronized with the packaging line, an AGV (Automated Guided Vehicle) system that executes a job to move materials from the palletizer to a AWS (Automated Warehouse System). Each of these systems perform independent job, with their own local Work Masters and workflows.

A Job Order contains values for job specific parameters (such as “Use By Dates” to be applied to labels), material requirements (such as an identification and quantity of the material lot to be produced), equipment requirements (such as which packaging line to use), personnel requirements for the job order (such as training requirements), and physical asset requirements (such as which testing equipment to use).

4.2 Job Order Information Model

The information objects identified in Figure 2 are used to describe a Job Order. This is a subset of the ISA 95 Part 4, Edition 2 Job Order model, intended to meet a large percentage of situations where nested resource requirements and external linkages are not needed. See the ISA 95 Part 4 specification for details on the attributes and relationships.

Job Order – The specification of a job to be executed.

Job Order Parameter - Additional information associated with the Job Order is represented in name/value pairs and defined Job Order Parameters.

Personnel Requirement – Information associated with the Job Order that defines additional personnel and/or person requirements.

Equipment Requirement – Information associated with the Job Order that defines additional equipment class and/or equipment requirements.

Physical Asset Requirement – Information associated with the Job Order that defines additional physical asset class and/or physical asset requirements.

Material Requirement – Information associated with the Job Order that defines additional material class, material definition, material lot, and/or material sublot requirements.

See Annex C for examples of Job Orders.

Note that the data types and enumerations used in this companion specification use the ISA 95 names, with the ISA95 prefix.

4.3 Job Response

A Job Response is a report on work done for a Job Order. The information objects identified in Figure 3 are used to describe a Job Response. This is a subset of the ISA 95 Part 4, Edition 2 Job Response model, intended to meet a large percentage of situations where nested resource actuals and external linkages are not needed. See the ISA 95 Part 4 specification for details on the attributes and relationships.

Job Response – The report on the execution of a Job Order.

Job Response Data - Additional information associated with the Job response is represented in name/value pairs and defined Job Response Data.

Personnel Actual – Information associated with the Job Response that defines additional personnel and/or person actuals.

Equipment Actual – Information associated with the Job Response that defines additional equipment class and/or equipment actuals.

Physical Asset Actual – Information associated with the Job Response that defines additional physical asset class and/or physical asset actuals.

Material Actual – Information associated with the Job Response that defines additional material class, material definition, material lot, and/or material sublot actuals.

5 Modelling Approach of ISA-95

The modelling approach for generating a UA model from the ANSI/ISA-95 Part 3 specification follows the following general concepts.

An OPC UA server may support the activity of receiving unsolicited Job Orders for processing.

An OPC UA server may support the activity of receiving unsolicited requests for Job Responses.

An OPC UA server may support the activity of receiving unsolicited Job Responses.

Data types from the ISA-95 model are mapped to OPC UA DataTypes (i.e. strings if localized are mapped to LocalizedText).

6 ISA-95 Data Representation Model

6.1 General

The OPC UA ISA-95 Information Model is a representation of the ISA-95 data model in OPC Methods, ObjectTypes, VariableTypes, DataTypes and ReferenceTypes.

This model generates standard types. All ISA-95 types will be defined in their own namespace and will begin with “ISA95”

The following conventions apply to ObjectType, VariableType and DataType naming:

All ObjectTypes include “ObjectType” as part of the name

All DataTypes that are structures include “DataType” as part of the name, this is to be able to differentiate them from any VariableTypes that will just end in Type.

All enumerations will end in “Enum”, to clearly identify that it is an enumeration.

All base DataTypes (int32, float, …) used in the OPC UA server will be those defined in OPC UA, see OPC 10000-6 for more detail on the representation of the datatypes.

6.2 ObjectTypes

6.2.1 ISA95JobOrderReceiverObjectType

6.2.1.1 Overview

The ISA95JobOrderReceiverObjectType contains methods to receive job order commands and optional definitions of allowable job order information as illustrated in Figure 4.

In addition, it provides information about the StateMachine of the job orders managed by instances of the ObjectType. As the job orders are not represented as Objects in the AddressSpace, but just as structured values, this ObjectType only provides the meta data of the StateMachine. It may be subtyped to add additional substates.

In Figure 5, an overview of the states is given. Note that this ObjectType does not define the substates of NotAllowedToStart, AllowedToStart, Ended and Interrupted. This is done in the ISA95JobOrderStateMachineType, defined in 6.2.2. The dotted states and transitions are not represented in the StateMachine at all. They express how job orders are added and removed from the system (InitialState and EndState and their transitions) and a logical state (Prepared) which is always exposed by its subtypes NotAllowedToStart and AllowedToStart.

A job order is added to the system by calling the Store or StoreAndStart Method defined on the ISA95JobOrderReceiverObjectType or by some internal mechanisms. Afterwards, the job order is in the state NotAllowedToStart or AllowedToStart. In both states, the job order is not executed. Using the Update Method, the job order may still be changed. Calling the Start Method switches the state from NotAllowedToStart to AllowedToStart, and calling RevokeStart vice versa.

When a job order is in the state AllowedToStart, the system may automatically start the job order depending on available recourses and priorities in case several job orders are in the same state. If the AllowedToStart state provides substates, they may indicate if a job order can be started (e.g. Waiting indicates that it cannot be started).

When the job order starts to be executed, it switches its state to Running.

Clients may interrupt a running job order by calling the Pause Method. The system may also automatically interrupt the job order. In both cases, the state switches to Interrupted. Substates may indicate if the interruption was triggered from external (Suspended) or automatic (Held).

Clients may resume the execution of an interrupted job by calling the Resume Method, or the system may automatically continue. In both cases, the state switches back to Running.

A job order may be aborted by calling the Abort Method. This can be done while the job order is running, interrupted or not even started (AllowedToStart and NotAllowedToStart). In all cases, the state switches to Aborted.

When the job order was executed, it automatically switches in the state Ended. Substates of Ended may expose whether some postprocessing needs to be done before receiving the final results of the execution.

Some job orders may not be defined to finish its execution automatically. In addition, some job orders may get stopped before the planned amount of the job order is produced. In both cases, the Stop Method is called to end the execution of the job order. This can either be done while in Running or in Interrupted. In both cases, it switches into Ended.

When the job order is either Aborted or Ended, the job order may be deleted from the system by calling the Clear Method. This is typically done by a specific Client after the Client has received the final results of the job order execution.

A job order that has not been started (AllowedToStart or NotAllowedToStart) may be removed from the system before execution by calling the Cancel Method.

6.2.1.2 TypeDefinition

The ObjectType is formally defined in Table 12. Note that the transitions do not expose causes as the StateMachine is not used on an individual Object exposing its state, but just as meta data for values.

The components of the ObjectType have additional references which are defined in Table 13.

The component Variables of the ISA95JobOrderReceiverObjectType have additional Attributes defined in Table 14.

JobOrderList - Defines a read-only list of job order information available from the server. The information returned is defined by the server and may be a complete copy of a received job order or may be just the IDs and the state of the job orders. If there are no job orders available from the server, then this may be null.

MaxDownloadableJobOrders – Defines the maximum number of job orders that can be managed at the same time. As all managed job orders are accessible in the JobOrderList, it restricts the length of that array. Max of UInt16 indicates, that there is no limit.

WorkMaster - Defines a read-only set of work master IDs that may be specified in a job order, and the read-only set of parameters that may be specified for a specific work master. If there are no restrictions on what work master IDs can be sent with a job order, then this may be null.

Recipes associated with the job order are identified using the WorkMasterID. The ID in the ISA95WorkMasterDataType is an identification of the Work Master and can be internal identifications, NodeIds, web links, or a client and server agreed to format.

MaterialClassID - Defines a read-only set of Material Classes IDs that may be specified in a job order. If there are no restrictions on what Material Classes IDs can be sent with a job order, then this may be null.

MaterialDefinitionID - Defines a read-only set of Material Definition IDs that may be specified in a job order. If there are no restrictions on what Material Definition IDs can be sent with a job order, then this may be null.

EquipmentID - Defines a read-only set of Equipment Class IDs and Equipment IDs that may be specified in a job order. If there are no restrictions on what Equipment IDs can be sent with a job order, then this may be null.

PhysicalAssetID - Defines a read-only set of Physical Asset Class IDs and Physical Asset IDs that may be specified in a job order. If there are no restrictions on what Physical Asset IDs can be sent with a job order, then this may be null.

PersonnelID - Defines a read-only set of Personnel IDs and Person IDs that may be specified in a job order. If there are no restrictions on what Personnel IDs can be sent with a job order, then this may be null.

The ObjectType inherits from the 0:FiniteStateMachineType to provide the StateMachine all job orders managed by the instances of the ObjectType support. The mandatory CurrentState inherited shall always return a BAD StatusCode, as the Object only provides the meta data of the states of the job orders provided in the JobOrderList. The ObjectType may provide be subtyped to provide SubStateMachines for specific states and also the AvailableStates and AvailableTransitions Variables may be provided to restrict the usage of the StateMachine.

6.2.1.3 Store Method

This Method receives a new job order and stores the new job order in local storage, but does not start the job order. After successful execution of the method, the JobOrderList shall have a new entry in state NotAllowedToStart.

The signature of this Method is specified below. Table 15 and Table 16 specify the Arguments and AddressSpace representation, respectively.

Signature

	Store (
	[in]	ISA95JobOrderDataType		JobOrder
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method result codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.4 StoreAndStart Method

This Method receives a new job order and stores the new job order in local storage, and start it as soon as the Job Order receiver is ready to start. After successful execution of the method, the JobOrderList shall have a new entry in state AllowedToStart. Note: the system may internally start executing the job order immediately, so potentially the job order is already in a different state when accessed the first time.

The signature of this Method is specified below. Table 17 and Table 18 specify the Arguments and AddressSpace representation, respectively.

Signature

	StoreAndStart (
	[in]	ISA95JobOrderDataType		JobOrder
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.5 Start Method

This Method starts a job order as soon as the Job Order receiver is ready to start. After successful execution of the method, job order in the JobOrderList shall be in state AllowedToStart.

If multiple job orders have been commanded to start, then the priority and timing values in the job orders shall be used to determine the order of execution of the job orders.

The signature of this Method is specified below. Table 19 and Table 20 specify the Arguments and AddressSpace representation, respectively.

Signature

	Start (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.6 RevokeStart Method

This Method revokes a not started job (in AllowedToStart). After successful execution of the method, job order in the JobOrderList shall be in state NotAllowedToStart.

The signature of this Method is specified below. Table 21 and Table 22 specify the Arguments and AddressSpace representation, respectively.

Signature

	RevokeStart (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4 or Annex B Table 94, and Table 95).

6.2.1.7 Pause Method

This Method pauses a started job. After successful execution of the method, job order in the JobOrderList shall be in state Interrupted.

The signature of this Method is specified below. Table 23 and Table 24 specify the Arguments and AddressSpace representation, respectively.

Signature

	Pause (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.8 Resume Method

This Method resumes an interrupted job (in state Interrupted). After successful execution of the method, job order in the JobOrderList shall be in state Running.

The signature of this Method is specified below. Table 25 and Table 26 specify the Arguments and AddressSpace representation, respectively.

Signature

	Resume (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.9 Update Method

This Method updates an existing job order that has not yet been started, with the new order information. All previously stored information is replaced.

The signature of this Method is specified below. Table 27 and Table 28 specify the Arguments and AddressSpace representation, respectively.

Signature

	Update (
	[in]	ISA95JobOrderDataType		JobOrder
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.10 Abort Method

This Method aborts a job order. After successful execution of the method, job order in the JobOrderList shall be in state Aborted.

The signature of this Method is specified below. Table 29 and Table 30 specify the Arguments and AddressSpace representation, respectively.

Signature

	Abort (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94 and Table 95).

6.2.1.11 Stop Method

This Method stops a started job order. After successful execution of the method, job order in the JobOrderList shall be in state Ended.

The signature of this Method is specified below. Table 31 and Table 32 specify the Arguments and AddressSpace representation, respectively.

Signature

	Stop (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.12 Cancel Method

This Method cancels a not started job order (in AllowedToStart or NotAllowedToStart) and removes the stored information. After successful execution of the method, there shall be no job order with the JobOrderID in the JobOrderList.

The signature of this Method is specified below. Table 33 and Table 34 specify the Arguments and AddressSpace representation, respectively.

Signature

	Cancel (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Note: This specification does not define how a client can access the last comment. It may be displayed in a local HMI or provided in the parameters of the job response.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.1.13 Clear Method

This Method clears any maintained information on the Job Order (usually sent after a receipt of a Job Response with a status of Finished.). After successful execution of the method, there shall be no job order with the JobOrderID in the JobOrderList.

Note: It is server-specific whether Job Orders get cleared by the Server automatically when it runs out of resources or after a period of time or other reasons.

The signature of this Method is specified below. Table 35 and Table 36 specify the Arguments and AddressSpace representation, respectively.

Signature

	Clear (
	[in]	0:String				JobOrderID
	[in]	LocalizedText[]			Comment
	[out]	0:UInt64			   	ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.2 ISA95JobOrderReceiverSubStatesType

6.2.2.1 Overview

This ObjectType describes the overall state of a job order including common SubStateMachines. As the job orders are not represented as Objects in the AddressSpace, but just as structured values, this StateMachine only provides the meta data of the state machine. It may be subtyped to add additional substates.

6.2.2.2 TypeDefinition

The ObjectType formally defined in Table 37.

The components of the ObjectType have additional references which are defined in Table 38.

The component Variables of the ISA95JobOrderReceiverSubStatesType have additional Attributes defined in Table 39.

6.2.3 ISA95PrepareStateMachineType

This ObjectType describes a SubStateMachine that a job order may use while already stored in the system but not being executed. The ObjectType formally defined in Table 40.

The components of the ObjectType have additional references which are defined in Table 41.

The component Variables of the ISA95PrepareStateMachineType have additional Attributes defined in Table 42.

6.2.4 ISA95EndedStateMachineType

This ObjectType describes a SubStateMachine that a job order may use after being executed. The ObjectType formally defined in Table 43.

The components of the ObjectType have additional references which are defined in Table 44.

The component Variables of the ISA95EndedStateMachineType have additional Attributes defined in Table 45.

6.2.5 ISA95InterruptedStateMachineType

This ObjectType describes a SubStateMachine a job order may use when being interrupted. The ObjectType formally defined in Table 46.

The components of the ObjectType have additional references which are defined in Table 47.

The component Variables of the ISA95InterruptedStateMachineType have additional Attributes defined in Table 48.

6.2.6 ISA95JobOrderStatusEventType

The ObjectType defines Events that can be send out every time the state of a job order is changing.

Table 49 contains the AddressSpace definition of an ISA95JobOrderReceiverObjectType.

The JobOrder contains the planned job order received by the system.

The JobState contains the current state of the job order. Clients may filter for Events of specific states, for example only receiving Events of ended job orders. The array shall provide at least one entry representing the top level state and potentially additional entries representing substates. The first entry shall be the top level entry, having the BrowsePath set to null. The order of the substates is not defined.

The JobResponse contains the current job response of the job order. The State in the JobResponse shall be identical to the JobState.

6.2.7 ISA95JobResponseProviderObjectType

6.2.7.1 Overview

The ISA95JobResponseProviderObjectType contains a method to receive unsolicited job response requests as illustrated in Figure 6.

Table 50 is the AddressSpace definition of an ISA95JobResponseProviderObjectType.

RequestJobResponseByJobOrderID – Defines the ISA95JobResponseRequest Method which receives requests for Job Responses by JobOrderID.

RequestJobResponseByJobOrderState – Defines the ISA95JobResponseRequest Method which receives requests for Job Responses by JobOrderState.

The ISA95JobOrderReceiverObjectType with the StoreAndStart Method may be paired with an ISA95JobResponseProviderObjectType and the RequestJobResponseByJobOrderID Method, to send a Job Order and query for a JobResponse. This transaction is illustrated in Figure 7.

Objects may generate Events of ISA95JobOrderStatusEventType for every change of the state of a job order managed by the Object. In that case, the JobResponse of the Event shall be identical to the entry in the JobOrderResponseList of the job order and the JobOrder to the counterpart job order receiver Objects JobOrderList.

The JobOrderResponseList, if provided, shall contain one entry for each job order of the corresponding job order receiver Object provided in the JobOrderList which is not in the states AllowedToStart or NotAllowedToStart. That means, for all job orders that have at least started the execution and are still managed by the job order receiver Object, there shall be an entry. The states of the job orders in both lists (JobOrderList and JobOrderResponseList) shall match for each job order.

When a Job Order gets removed from the JobOrderList, it shall also get removed from the JobOrderResponseList.

6.2.7.2 RequestJobResponseByJobOrderID Method

This Method is used to return Job Responses for unsolicited requests for responses from a job order.

The signature of this Method is specified below. Table 51 and Table 52 specify the Arguments and AddressSpace representation, respectively.

Signature

	RequestJobResponseByJobOrderID (
		[in]	0:String				JobOrderID	
	[out]	ISA95JobResponseDataType	JobResponse
	[out]	0:UInt64	   	 		ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.7.3 RequestJobResponseByJobOrderState Method

This Method is used to return Job Responses for unsolicited requests for responses from a job order.

The signature of this Method is specified below. Table 53 and Table 54 specify the Arguments and AddressSpace representation, respectively.

Signature

	RequestJobResponseByJobOrderState (
		[in] 	ISA95StateDataType[]	 	JobOrderState
	[out]	ISA95JobResponseDataType[]	JobResponses
	[out]	0:UInt64	   	 		ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.2.8 ISA95JobResponseReceiverObjectType

6.2.8.1 Overview

A Job Response Receiver receives unsolicited Job Responses, usually as the result of completion of a job, or at intermediate points within the job as illustrated in Figure 8.

Table 55 is the AddressSpace definition of an ISA95JobResponseReceiverObjectType.

ReceiveJobResponse – Defines the ReceiveJobResponse Method which receives unsolicited Job Responses.

The ISA95JobOrderReceiverObjectType with the ReceiveJobOrder method may often be paired with an ISA95JobResponseReceiverObjectType and the ReceiveJobResponse method, to send a Job Order and receive a JobResponse. This transaction is illustrated in Figure 9.

6.2.8.2 ReceiveJobResponse Method

The ReceiveJobResponse method is used to receive unsolicited Job Responses.

The signature of this Method is specified below. Table 56 and Table 57 specify the Arguments and AddressSpace representation, respectively.

Signature

	ReceiveJobResponse(
	[in]	ISA95JobResponseDataType		JobResponse
	[out]	0:UInt64			   		ReturnStatus
	);

B.2 defines common values for ReturnStatus.

Method Result Codes are defined as part of the Call service (see OPC 10000-4, or Annex B Table 94, and Table 95).

6.3 DataTypes

6.3.1 ISA95EquipmentDataType

The ISA95EquipmentDataType is a subtype of OPC UA Structure that defines an equipment class or a specific piece of equipment, a quantity and unit of measure, an optional description, and an optional collection of properties.

The structure is defined in Table 58.

Table 59 is the AddressSpace definition of an ISA95EquipmentDataType.

6.3.2 ISA95StateDataType

The ISA95JobOrderDataType is a subtype of OPC UA Structure that defines the information needed to schedule and execute a job.

The structure is defined in Table 60.

Table 61 is the AddressSpace definition of an ISA95StateDataType.

6.3.3 ISA95JobOrderAndStateDataType

The ISA95JobOrderAndStateDataType is a subtype of OPC UA Structure that defines the information needed to schedule and execute a job, including its state.

The structure is defined in Table 62.

Table 63 is the AddressSpace definition of an ISA95JobOrderAndStateDataType.

6.3.4 ISA95JobOrderDataType

The ISA95JobOrderDataType is a subtype of OPC UA Structure that defines the information needed to schedule and execute a job.

The structure is defined in Table 64.

Table 65 is the AddressSpace definition of an ISA95JobOrderDataType.

6.3.5 ISA95JobResponseDataType

The ISA95JobResponseDataType is a subtype of OPC UA Structure that defines the information needed report on the execution of a job order.

The structure is defined in Table 66 .

Table 67 is the AddressSpace definition of an ISA95JobResponseDataType.

6.3.6 ISA95MaterialDataType

The ISA95MaterialDataType is a subtype of OPC UA Structure that defines a material resource, and an optional description, material use, quantity and unit of measure, description, and collection of properties.

The structure is defined in Table 68.

Table 69 is the AddressSpace definition of an ISA95MaterialDataType.

6.3.7 ISA95PersonnelDataType

The ISA95PersonnelDataType is a subtype of OPC UA Structure that defines a personnel resource and an optional description, personnel use, quantity and unit of measure, description, and collection of properties.

The structure is defined in Table 70.

Table 71 is the AddressSpace definition of an ISA95PersonnelDataType.

6.3.8 ISA95PhysicalAssetDataType

The ISA95PhysicalAssetDataType is a subtype of OPC UA Structure that defines a physical asset resource and an optional description, physical asset use, quantity and unit of measure, description, and collection of properties.

The structure is defined in Table 72.

Table 73 is the AddressSpace definition of an ISA95PhysicalAssetDataType.