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.

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.

Figure 1 – Overview JobManagementType

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.

Figure 2 – Integration of Job Management into MachineryItem

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.

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.

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.