OPC UA for MES Is Not Enough Without a Job Model

OPC UA handles connectivity, data reads, subscriptions, methods and channel security very well. But having OPC UA on a machine does not mean that an MES understands a production job, can queue it or will receive an unambiguous completion report.

If a system only needs the operating mode, alarms, counters and current load, it is too early to add ISA-95 Job Control. If the MES must send an order, quantity, program and material requirements, authorize a start, stop work and receive the result, arbitrary tags are no longer enough. You need an agreed job model, even if the project team decides not to implement the standard exactly.

OPC UA handles communication, not job meaning

OPC UA provides the means of exchange, but data only gains meaning through an information model. A server may publish a ProductionOrder variable of type String, and any client can read it without error. Yet the string does not reveal whether it is an ERP order number, a shift job, a batch, a routing operation or the name of a CNC program.

Projects constantly blur this distinction. The protocol answers "how do I read this?", "how do I call a method?", "how do I subscribe?" and "who has access?". The production model answers "what exactly has been assigned?", "what resource is needed?", "can the assignment be changed?" and "which result belongs to which order?".

OPC Foundation describes this model in OPC 10031-4, OPC UA for ISA-95, Part 4: Job Control. The document defines Job Order, Job Response, access to queued, executing and completed jobs, and methods for managing them. It is not an OPC UA competitor, but a companion specification built on top of it.

There is also OPC 40001-3, OPC UA for Machinery, Part 3: Job Management, for general-purpose equipment. It uses Job Control types and specifies machine parameters: planned quantity, number of starts, planned time, execution mode, order numbers and result data. In OPC UA for Machine Tools version 1.02, the earlier ProductionType model is already marked obsolete and points to a future replacement by Machinery Job Management. Buying a new machine based solely on an old list of production tags means planning for a later adapter rewrite.

There is another boundary. ISA-95 Job Control does not define the process logic for machining a part. Feeds, tool offsets, sequence steps, chuck interlocks and safe stops remain in the CNC and PLC. The MES manages the assignment, not axis motion.

Monitoring does not require Job Control

Simple parameter collection does not require a job model if the MES or a separate monitoring system does not control machine operation. Structured telemetry is usually enough to calculate utilization and analyze downtime.

A minimum monitoring contract includes:

• equipment status and operating mode;
• automatic-cycle activity and the reason for stopping;
• good-part and scrap counters;
• alarms with code, occurrence time and acknowledgement time;
• the identifier of the active program or current job, if the machine already knows it.

Every value needs a source, type, unit of measure, timestamp and OPC UA StatusCode. A counter without a reset rule is useless. A Running state without a definition is equally useless: one supplier considers a machine running when the spindle rotates, another when a program is active, and a third when the alarm signal has cleared.

For this scenario, OPC UA subscriptions are usually better than frequent polling. The client receives changes with server timestamps and quality control. The publishing rate must match the task: a production dashboard does not need controller-cycle data, while analyzing short stops loses value with infrequent sampling.

Do not attach an order to every temperature and axis position. Telemetry describes the state of a physical object. Production context links some of that data to a specific job. If you mix these layers, changing an order number breaks historical trends, while replacing a sensor forces changes to the MES model.

The practical criterion is simple: if, after a connection loss, the MES does not need to send anything to the machine again and can simply resume reading after recovery, Job Control is not yet required. Everything changes when a lost message can leave behind two jobs, the wrong program or an unclosed order.

The MES begins to control when Job Order appears

A Job Order model is needed when the upper-level system assigns a unit of work to a specific work center. ISA-95 calls a Job Order a request to perform work and places it below a Work Request in the production scheduling structure. In metalworking, that unit is often an order operation on a specific machine, rather than the entire customer order.

At a minimum, a good job answers these questions:

• what is its stable identifier and which order does it belong to;
• what must be made and in what quantity;
• which Work Master, routing, program or document revision defines how the work is done;
• what equipment, material, tooling or qualification is required;
• when the job may start and what its priority is.

A field containing the CNC program number does not replace a Work Master. A CNC program describes machining on a specific CNC system. The production definition may also include a setup sheet, inspection plan, fixturing instruction, drawing revision and scrap-recording rules. The MES may refer to an approved package, while the local machine system must verify that the required version is available.

Not every requirement has to reach the controller. An operator qualification requirement may be checked at a shop-floor terminal. A blank-material lot may be confirmed by a scanner. A fixture identifier may be checked by the PLC or the operator. A Job Order brings these requirements together in one context, but does not require one server to enforce them all.

Priority and start time are not the same as an immediate-start command. OPC 40001-3 orders several authorized jobs first by StartTime, then by Priority; if they are equal, selection remains application-dependent. This is a sensible caveat. The scheduler proposes an order, while the machine begins work only after local readiness is checked.

Job Response closes the production loop

Job Response matters to an MES as much as Job Order, because a command without a confirmed result leaves the order in an uncertain state. The standard defines a response as a report on work performed for a job and separates requirements in the order from actual data in the response.

This separation is often damaged by a single Material object. In an order, material means a requirement: grade, size, lot or allowed class. In a response, Material Actual means what was actually used. If you replace the requirement with the fact, the MES will not detect a lot substitution or restore traceability.

The same logic applies to equipment, physical assets and personnel. Equipment Requirement may require a machine of a specific class. Equipment Actual records the specific work center. Physical Asset Requirement may describe a type of measuring instrument, while Physical Asset Actual stores the identifier of the instrument actually used. These pairs are needed to answer a routine quality-department question: "What machine and material were used for this exact lot?"

The response must contain an intermediate state for a long operation and a final result after completion. OPC 40001-3 provides JobResult values of Unknown, Successful and Unsuccessful, along with output and performance data. Successful alone is not enough: the MES needs actual quantity, scrap, start and finish times and, where necessary, identifiers for the parts or lots produced.

State and result must not be combined. Running describes the current phase. Successful evaluates completed work. A machine may stop normally after producing a smaller quantity, and the business system decides whether the order can be considered closed. The controller reports the fact; the MES applies the production rule.

One order line inevitably spreads out

Custom integration usually starts to fail after its first successful run, when real exceptions are added. In a demo, the MES writes OrderNo, PartNo, Quantity and a Start bit. The PLC runs the program, increments Produced and sets Done.

Then the network fails after writing Start but before reading the acknowledgement. The MES repeats the write. If the PLC treats the rising edge of the bit as a new command, the job starts a second time. If the bit remains set, no new start occurs, but the MES does not know whether the machine accepted the first one. The team adds Ack, then a sequence number, then Busy, then a timeout and manual reset.

Next, the scheduler changes the quantity before the start. It is unclear whether fields can change while Busy=0 if the operator has already loaded material. Locked appears. Then the operator pauses the job to measure the first part. The system must distinguish a process pause, an alarm and cancellation. Pause, Hold, Fault, Cancel, Abort and several transition tables appear, with the MES and PLC interpreting them differently.

Then comes the requirement to account for a partially completed order. The old Done field does not say whether 80 of 100 parts were produced, whether the remaining 20 were cancelled or whether a continuation can be created under the same number. The team adds an execution batch number. A year later, the project has its own job model, only without shared terminology, interoperability profiles or documentation for the next machine supplier.

The popular advice "start with four tags, then expand" is not bad because the start is small. It is bad when the four tags already serve as an external contract but have no stable command identifier, defined state machine or retry rules. A small pilot is acceptable if the team documents the boundaries from the start and does not present a temporary scheme as a finished architecture.

Job Control does not automatically eliminate mistakes. It requires you to name objects, states and methods before commissioning. That work usually reveals that the MES, PLC programmer and manufacturing engineer mean different things by the word "job".

A data contract matters more than a tag list

A working contract must show more than fields. It must show direction, whether each field is required, who owns the value and how duplicates are handled. Below is a simplified representation of a job for a turning operation. It is not OPC UA programming and not an exact serialization of ISA95JobOrderDataType, but a testable project artifact for aligning the MES, gateway and machine system.

{
  "jobOrderId": "WO-78431-OP20-R1",
  "workMasterId": "SHAFT-A-OP20-REV4",
  "startTime": "2026-07-27T06:00:00Z",
  "priority": 60,
  "parameters": {
    "orderNumber": "WO-78431",
    "drawingNumber": "SHAFT-A",
    "drawingRevision": "04",
    "plannedQuantity": 120,
    "executionMode": "ProductionMode"
  },
  "materialRequirements": [
    {
      "materialDefinitionId": "STEEL-40X-D52",
      "plannedQuantity": 120,
      "unit": "piece"
    }
  ],
  "equipmentRequirements": [
    {
      "equipmentClassId": "CNC-LATHE-D65"
    }
  ]
}

Here, the jobOrderId identifier refers to a specific execution of an operation. Resending the same identifier must not create a second job. If the scheduler intentionally releases a new revision, it creates a new identifier or applies the standard-permitted Update before the job enters a state in which changes are prohibited. Choose the rule in advance and test it in a test environment.

The response must reference the same identifier and separate facts from the plan:

{
  "jobOrderId": "WO-78431-OP20-R1",
  "state": "Ended",
  "jobResult": "Successful",
  "actualStartTime": "2026-07-27T06:14:08Z",
  "actualEndTime": "2026-07-27T13:42:31Z",
  "producedQuantity": 120,
  "scrapQuantity": 2,
  "materialActuals": [
    {
      "materialLotId": "HEAT-91827",
      "consumedQuantity": 122,
      "unit": "piece"
    }
  ],
  "equipmentActuals": [
    {
      "equipmentId": "LATHE-07"
    }
  ]
}

This example immediately raises difficult questions. Does producedQuantity include scrap? Can a successful job include scrap? Who assigns materialLotId? How do you report two metal lots? When does a result become final? Until these answers are documented, the integration remains a set of assumptions.

A state machine protects against duplicate execution

Defined state transitions reduce the risk of repeated starts and conflicting commands, but only if client and server both follow them. OPC 10031-4 describes a job receiver with the methods Store, StoreAndStart, Start, RevokeStart, Pause, Resume, Update, Abort, Stop, Cancel and Clear.

The names resemble ordinary buttons, but the differences are significant. Pause assumes that work can continue later. Stop ends execution in a controlled way according to equipment rules. Abort is used when normal continuation is no longer required. Cancel applies to a job that must not be executed. The project must map these intentions to the real capabilities of the CNC and PLC. Do not promise the MES a resumable pause if the machine cycle cannot support it safely.

StoreAndStart does not mean an unconditional physical start either. In the model, a job is authorized for execution, after which the system considers resources, priorities and local conditions. The "Cycle Start" button can remain with the operator if the process or risk assessment requires it.

After a timeout, the client must not blindly repeat a command. A reliable sequence is as follows: the MES stores the jobOrderId and attempt identifier, calls the method, and if the response is lost, reads the job list and current state. A retry is allowed only after verifying that the server did not accept the original assignment. Idempotency here is a property of agreed behavior, not transport magic.

In Annex B of OPC 10031-4, method result codes are defined as a UInt64 bitmask. Standard reasons include an unknown job identifier, an invalid state, inability to accept a job and an invalid request. Document the expected MES response to each code. Endless automatic retries after Unable to accept Job Order quickly turn a temporary problem into a queue of identical messages.

A secure channel does not give an MES the right to issue a dangerous command

OPC UA security mechanisms protect the connection, but the designer must still limit client permissions and the commands available in every machine state. A certificate verifies the connection party and helps protect data in transit. It does not decide whether a scheduler account should be allowed to call Abort during machining.

Separate, at a minimum, monitoring reads, job upload, execution authorization and emergency intervention. The MES service account should not have server administrator rights simply because that makes a test setup easier. Separately log the client identifier, method, jobOrderId, time, source state and call result.

The enterprise network does not replace local safety either. The PLC and CNC must verify guards, clamping, drive readiness, program availability and other conditions independently of an MES command. The upper-level system can request the start of an authorized job, but it must not bypass safety circuits or machine logic.

Plan for degraded operation when communication is lost. An executing operation should normally either continue safely under local control or stop according to a predefined rule. Do not leave that decision to a client-library timeout. After recovery, the MES must receive the actual state and results, rather than assign the machine a state from its old copy.

Implement the full model by responsibility boundary

Not every plant needs the entire ISA-95 model in the first release. You need a minimum profile that covers the MES's real responsibility and can evolve without changing the meaning of identifiers.

It is useful to divide implementation into three levels. At the first level, the MES only reads standardized telemetry. At the second, it maps an active local job to an order, but the operator loads and starts it on the machine. At the third, the MES creates a Job Order, manages permitted transitions and accepts a Job Response. Move to the next level only after testing the previous one against communication loss, restarts and manual actions.

When selecting an implementation, request more than the statement "OPC UA is supported". Ask for the specific NamespaceUri, NodeSet versions, profiles and Conformance Units. It is especially important to fix the Job Control version: version 2 of OPC 10031-4 contains changes incompatible with version 1 and uses a new namespace. A client written for the old model will not become compatible merely by replacing node addresses.

Also check OPC 40001-3 Machinery Job Management. The base profile requires JobOrderControl and JobOrderResults, but individual planned parameters and results are assigned to separate Conformance Units. A server may genuinely support the base model yet lack the PlannedOrderQuantity, material results or performance information you need. Confirm this through the profile and testing, not marketing copy.

When selecting and commissioning an EAST CNC machine, include the integration profile in the technical specification before delivery. Aligning semantics later is almost always more expensive because the MES, gateway and PLC will already be built on different assumptions.

Acceptance testing must break the happy path

An integration is ready when it handles failures predictably, not when one order succeeds in a test environment. Acceptance tests must include repeated methods, connection loss and conflicting commands.

Run at least five checks:

1. Send one jobOrderId twice and verify that the server did not create two jobs.
2. Break the connection after the job is accepted but before the method response, then restore state without starting it again.
3. Try to update the quantity before the start and during execution, checking permitted transitions.
4. Perform pause, resume, controlled stop and cancellation in the states where the equipment claims support.
5. Complete a job partially, with scrap and with a material-lot substitution, then verify the Job Response in the MES.

For every test, define the expected state, method code, log entry and business outcome in advance. "An error appeared" is not suitable for acceptance. You need a specific StatusCode, ReturnStatus, preserved jobOrderId and no unintended machine movement.

If the MES only observes, keep Job Control out of scope and define the telemetry thoroughly. If the MES directs work, adopt a job model before writing tags. Otherwise, the team will build Job Control anyway, but accidentally, one emergency fix at a time.