ISA-95 Job Control V2
| Document | - |
|---|---|
| Version | 2.0.0 |
| Published | 2024-01-31 |
| Namespace | http://opcfoundation.org/UA/ISA95-JOBCONTROL_V2/ |
| Sector | MES interface |
ISA-95 Job Control V2 is the standard MES-to-machine work order handshake in OPC UA: the MES sends a structured job order, the machine reports job state, and a job response carries results back. Version 2.0.0 dates from 2024-01-31 and is the model to target for new MES integration.
Where it sits in the stack
This is the vertical interface, not a machine model. Job Control sits above whatever describes the equipment itself, so a real installation pairs it with Machinery or a sector model for identification and state, and uses Job Control only for the order handshake. It supersedes the 2013 ISA-95 nodeset in practice and is designed alongthe ISA-95 common object model, which the family also publishes as a separate common model document. On the machine side, Machinery Jobs covers similar ground from the equipment vendor's direction, and the two overlap: decide early which one is authoritative in your architecture rather than implementing both.
The types that matter
| Type | What it carries |
|---|---|
ISA95JobOrderReceiverObjectType | The object a machine or line controller exposes to receive job orders. It carries the job order list, the current state and the methods the MES calls, so this is the object to find first when you browse an ISA-95 server. |
ISA95JobOrderDataType | The job order itself: order identifier, work master, start and end time, priority and the parameter, material, equipment, personnel and physical asset requirements. This is one large structure, not a set of tags. |
ISA95JobResponseDataType | What comes back when the job finishes or is aborted: the actuals for materials, equipment, personnel and parameters, plus job state and timing. This is the record your MES reconciles against. |
ISA95JobOrderAndStateDataType | A job order paired with its current state, used where the machine reports its queue rather than a single active order. |
ISA95StateDataType | The state of a job order as the machine reports it, which is what drives the MES view of whether work is queued, running or finished. |
ISA95ParameterDataType | The generic name, value, unit and subparameter structure used throughout the model wherever a recipe or setpoint has to travel with the order. Nested subparameters are how hierarchical recipes are carried. |
ISA95MaterialDataType | Material requirement or actual: class, definition, lot, sublot, quantity and unit. It is the hook for traceability, because the lot travels with the order. |
ISA95EquipmentDataType | Equipment requirement or actual, identifying which asset the order is assigned to or ran on. |
ISA95PersonnelDataType | Personnel requirement or actual, which is where operator attribution enters the record if your plant uses it. |
ISA95PhysicalAssetDataType | Physical asset requirement or actual, used for tooling, moulds and fixtures that are tracked as assets rather than as equipment. |
ISA95WorkMasterDataType | The reference to the work master or recipe the job order instantiates, with its parameters. It is how the machine knows which program to run. |
ISA95JobOrderStatusEventType | The event raised when a job order changes state, so a client can follow order progress without polling. |
Using it on a real machine
- Check the capability code and namespace firstRead the ServerCapabilities codes for S95 and check NamespaceArray for http://opcfoundation.org/UA/ISA95-JOBCONTROL_V2/. A server carrying only the 2013 URI is on the legacy model and needs a different integration design.
- Decide which side owns the job orderJob Control assumes one party dispatches and the other receives. Fix that before writing code, because the object you browse for and the methods you call differ depending on whether your application is the MES or the equipment.
- Load the nodeset so the structures decodeEvery payload here is a nested ExtensionObject. Load the ISA95-JOBCONTROL_V2 nodeset into your client so ISA95JobOrderDataType and ISA95JobResponseDataType decode by DataTypeDefinition. Without it you get opaque byte strings or a decoding failure, not a readable order.
- Subscribe to job state, do not poll the order listMonitor the job order state and the status event rather than reading the whole order list on a timer. Job orders are large structures and re-reading them at interval is a common cause of oversized responses.
- Reconcile the response against your own recordStore the job response as received, then compare its actual quantities against counts you collected independently from the machine. Divergence between the two is usually the first evidence that a job boundary was missed.
What it gives you for OEE
Job Control does not measure anything, and that is the point: it supplies the order context that OEE needs and machine models cannot provide. From the job order you get the product, the planned quantity, the work master and the planned start and end, which is what turns a raw count into a yield figure and what lets performance be compared against an intended rate. From the job response you get the actuals the MES will bill against. Availability, cycle counts and stop reasons still come from Machinery, MachineTool, PackML or the vendor's own tags. Treat it as the layer that gives your OEE numbers a denominator and a product attribution, and keep the measurement itself on the equipment side.
Gotchas
- Two namespaces exist and they are not compatible. The 2013 ISA-95 URI and the JOBCONTROL_V2 URI are different models with different type names; a server can carry both and mean the older one.
- Everything is a nested structure. Clients that cannot resolve DataTypeDefinition will report a decoding error rather than a partial order, and vendor MES products vary in how deeply they populate the nesting.
- MES vendors implement subsets. A product that claims ISA-95 job control may only carry the order identifier, the work master and a quantity, leaving materials, personnel and physical assets empty.
- The model does not define who resolves conflicts when a job order is rejected or superseded. That behaviour is per implementation and needs to be agreed in the interface specification, not assumed.
Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.
See Jemba →Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.