OPC UA Client/Server or PubSub for MES

Use OPC UA Client/Server to transfer machine data to MES when the MES must discover tags, read status on demand, receive changes with confirmation, and sometimes write jobs. PubSub makes sense when several consumers need the same telemetry stream, the machine count is growing, and the publisher should not maintain a separate connection with each consumer.

You cannot reduce the choice of communication model to «which one is faster». Latency depends on the controller cycle, sampling frequency, publishing interval, gateway queue, broker, and MES handler. A poor data model will cause more trouble than a few milliseconds on the network: the MES will receive the number 742 without a unit, source time, or quality indicator and record it as valid output.

In a running plant, I usually choose a hybrid. The machine or local gateway provides Client/Server for the address space, diagnostics, and commands, while prepared production event sets go to a broker through PubSub. A hybrid should not be the default answer, however. First separate the flows, check the capabilities of the actual MES, and run a test on your own network.

Start the choice with MES operations

An MES usually performs several different operations, and one transport pattern rarely serves all of them equally well. Collecting the current spindle speed, recording a completed part, loading a job, reading a stop reason, and confirming a command all need different semantics.

For periodic values, the MES needs a stream with an understandable source time, quality status, and equipment identifier. A «part completed» event needs a unique identifier, or repeat delivery will increase the output count. A job write needs a result response and a check that the command applies to the correct machine and recipe. For diagnostics, an engineer needs Browse, Read, and access to the address-space structure, not merely a set of fields selected in advance.

Client/Server naturally covers addressed operations. The client opens a secure channel and session, browses nodes, reads and writes attributes, calls methods, creates MonitoredItems, and groups them into a Subscription. PubSub transfers preconfigured DataSetMessages. The publisher does not know the receivers, and the subscriber does not have to know the publisher; UDP or a broker provides delivery between them.

This leads to the first design decision: separate the read interface, the event stream, and the command interface. If the MES only needs OEE with one-minute aggregation, a direct session to every controller may be unnecessary. If a dispatcher starts a job from the MES and must see a specific rejection code, a PubSub stream alone does not replace a request and response.

It helps to create a matrix before choosing a product:

The final row deliberately names no winner. Neither an OPC UA Session nor MQTT QoS by itself prevents the MES from posting the same production event twice. That belongs to the application contract.

Client/Server provides context and feedback

Client/Server better suits an MES that must explore and change a machine information model rather than just receive a fixed set of numbers. OPC UA Part 4 defines Browse, Read, Write, Call, and subscription services; the server returns a StatusCode for operations, so an integrator can see a partial failure in a batch request instead of guessing from silence.

A subscription here is not the same as PubSub. The client creates its own Subscription and MonitoredItems and sets the sampling and publishing intervals, change filter, queue size, and discard rule. The server holds state for that client. In its comparative annex, OPC UA Part 14 explicitly says this delivery uses buffering, acknowledgements, and retransmission, but consumes server resources for every connected client.

This helps an MES in several ways. First, the client can Browse during machine commissioning and verify that required nodes exist. Second, it can read an initial value before subscribing or after recovery. Third, it receives a sequence number and can request missed NotificationMessages again while the data remains in the server queue.

The guarantee has limits. Normal queues often live in memory, their size is finite, and a long network outage or server restart can cause loss. Durable Subscription exists in the specification, but it is a separate profile capability that both sides must support. You cannot write «OPC UA is reliable» in a project and close the question. Ask for the RevisedQueueSize, revised publishing interval, lifetime, and behavior after a restart from the actual server.

Client/Server also simplifies two-way work. The MES can call a method with arguments and get an execution code, or write a value under separate access control. I still do not allow an MES to write directly to process variables. A command must go to a dedicated node or method, and PLC logic must check the mode, recipe, interlocks, and repeated command identifier.

The cost of this clarity appears at scale. One hundred machines mean one hundred secure connections, sessions, sets of MonitoredItems, keep-alive timers, and reconnection paths. That is a normal load for a properly sized aggregating server, but a heavy one for a limited embedded CNC server. Measure limits on sessions and subscription items instead of inferring them from an OPC UA logo in a datasheet.

PubSub separates the machine from receivers

PubSub scales distribution of a predefined stream better because publisher work does not grow with the number of subscribers. Under OPC UA Part 14, a Publisher builds a DataSet, a WriterGroup sets the publishing behavior, and a DataSetWriter encodes messages. A Subscriber receives them through an intermediate transport and maps them to a DataSetReader.

With UDP UADP, a machine or gateway sends a binary message to a multicast group or a specific address. One packet can reach the MES, historian, energy monitoring system, and analytics. On a local segment with a controlled network, this gives the publisher predictable load and removes session establishment with every receiver. Normal UDP still offers best-effort delivery: a packet can be lost, arrive out of order, or be repeated after intermediate equipment acts on it.

With a broker, the Publisher sends UADP or JSON to an MQTT broker, and consumers subscribe to topics. The broker separates consumer lifetime from the machine, can retain messages according to its configuration, and distributes one stream to several systems. This is convenient when the MES is in another network segment or several applications need the data at once.

PubSub does not let the subscriber browse the entire address space at will. The DataSet defines in advance which fields go out. If an engineer adds a new downtime reason code, the metadata and consumer contract must change. That predictability is good for operations, but it requires version management.

A minimal completed-part event contract can look like this:

{
  "schemaVersion": 3,
  "machineId": "LINE2-LATHE04",
  "eventId": "LINE2-LATHE04-184467",
  "eventType": "PartCompleted",
  "sourceTime": "2026-07-26T14:08:31.482Z",
  "partNo": "A17-442",
  "quantity": 1,
  "quality": "Good"
}

eventId lets the MES accept a repeated message without posting it twice, schemaVersion separates compatible changes from incompatible ones, and sourceTime prevents broker receipt time from replacing machine time. The quality field must come from a verifiable source state rather than always containing the string Good.

Choose PubSub because a stable data contract exists, not because the broker is fashionable. If the tag set changes every week and the integrator constantly needs Browse, first stabilize the model through Client/Server or an aggregating gateway.

Measure latency across the entire chain

Neither model promises lower latency without qualifications because a network packet is only part of the path from a physical signal to an MES record. The signal first enters the PLC or CNC cycle, then the server or Publisher samples the value, encodes a message, transfers it, and the consumer parses and commits the result.

For Client/Server, the MonitoredItem sampling interval and Subscription publishing interval matter. The specification allows a server to revise an unsupported interval, so a requested 10 ms does not mean an actual 10 ms. If the source updates once every 100 ms, polling the server every 5 ms creates no new data. It only adds work.

For PubSub, the WriterGroup PublishingInterval, key-frame and delta-frame behavior, packet size, network-interface queue, and transport matter. UDP UADP can remove a broker hop. MQTT adds a broker and acknowledgements for the chosen QoS, but can outperform hundreds of poorly configured sessions through a shared queue and stable fan-out. A comparison only makes sense with the same fields and source frequency.

I measure four times: t_source on the machine, t_publish at the Publisher or server, t_receive on entry to the integration layer, and t_commit after a confirmed MES write. This reveals two distinct values:

transport_latency = t_receive - t_publish
end_to_end_latency = t_commit - t_source

The first shows network and delivery. The second shows what production experiences. Compare the median, 95th and 99th percentiles, maximum, share of lost events, and share of duplicates. A single average hides garbage-collector pauses, reconnects, and queue overflow.

Clocks must be synchronized, or negative latency will look like an improvement. If a machine does not support dependable time synchronization, timestamp at the nearest gateway and honestly call it observation time, not event time. For an emergency stop, also compare the physical input with the PLC log, or the test will cover only the attractive part of the chain.

Delivery within seconds is often sufficient for OEE, but a command or interlock may have a different limit. Do not turn MES into a real-time control loop. Axis motion, operator protection, and fast interlocks must remain in the controller, where network latency and failure cannot change the safe state of equipment.

Network load depends on changes and receivers

PubSub does not always create less traffic, and Client/Server does not always overload a network. The result depends on field count, change frequency, encoding, protocol headers, receiver count, and redelivery policy.

Consider a calculated example, not a performance promise. One hundred machines transmit 200 numeric values ten times a second. The useful 8-byte values alone amount to 1.6 Mbit/s. Identifiers, time, StatusCode, OPC UA headers, IP, and transport come on top. JSON increases volume considerably compared with binary UADP, especially when every field carries its name.

A Client/Server Subscription can send changes only and pack several Notifications into one message. A deadband filters analog-signal noise. If the MES is the only consumer and most values rarely change, this subscription can use less bandwidth than a periodic full DataSet.

UDP multicast sends one NetworkMessage regardless of the number of listeners in the same multicast domain. This is a strong advantage with several receivers, but multicast requires switch, IGMP snooping, VLAN, and routing-rule configuration. Uncontrolled multicast can spread the stream to ports that do not need it.

MQTT accepts one stream from the Publisher, then the broker sends separate copies to subscribers. Machine load stays predictable, but traffic and resource use do not disappear. They move to the broker and its outbound connections. QoS 1 and QoS 2 add acknowledgements and possible retransmissions. Message retention needs disk capacity and a clear expiry policy.

Calculate traffic separately on three segments: machine to gateway, gateway to broker, and broker to MES. Test normal operation and recovery after an outage. A system that calmly carries 5 Mbit/s can build a queue measured in gigabytes after the MES is unavailable for an hour if nobody limits lifetime and buffer depth.

Reliability and security do not come with the name

Client/Server provides mechanisms to detect gaps and retransmit NotificationMessages, but reliability lasts only while the Subscription and queues survive. PubSub delegates delivery properties to its transport. That makes phrases such as «encrypted OPC UA» and «MQTT with exactly once» too short for a technical specification.

For MQTT, OPC UA Part 14 maps best effort and at most once to QoS 0, at least once to QoS 1, and exactly once to QoS 2. QoS 1 permits duplicates. QoS 2 guarantees the exchange with the broker, but it does not guarantee that MES business logic will post an event exactly once. If the handler records output and then fails before committing the acknowledgement, the message can return. A unique eventId and a uniqueness constraint in the MES database close this gap better than an impressive QoS label.

UDP without an added mechanism does not confirm delivery. Loss of one packet may be acceptable for periodic telemetry if a complete key frame soon follows. Silent loss is unacceptable for a completed part or recipe change. Send such events through a reliable broker transport or duplicate them in an acknowledged interface.

In Client/Server, SecureChannel protects messages between client and server, applications use certificates, and the user or application authenticates according to configuration. You must manage trust lists, certificate expiry, private keys, disabled algorithms, and access revocation. A certificate that an operator once accepted manually «forever» turns a strict trust model into paperwork.

In PubSub over MQTT, TLS protects each leg to the broker. The broker can see the data and must be treated as a trusted party. Part 14 separately warns that JSON messages depend on MQTT and broker security; end-to-end message security is defined for UADP. UADP signing and encryption use group keys managed by a Security Key Service. That adds key rotation, security groups, and recovery after key expiry.

The practical rule is simple: draw the trust boundaries and name the owner of every certificate or group key. Then disable one certificate, rotate a key, restart the broker, and inspect the log. If the team cannot explain who restores the flow and how to distinguish a trust failure from a network outage, security still exists only on the diagram.

Check certificates by profile and MES by interface

A «supports OPC UA» label does not prove compatibility with the required model. OPC UA Part 7 separates Client, Server, Publisher, and Subscriber application profiles and adds Facets for specific functions and transports. A certified Server may not be a Publisher, and a certified Client need not accept MQTT UADP.

The OPC Foundation tests products against declared profiles and publishes a catalog that can filter Client, Server, Publisher, Subscriber, PubSub UDP UADP, MQTT JSON, and MQTT UADP. A procurement specification should name the exact profile, version, encoding, transport, and functions. A certification logo without a profile list says little about integration.

Ask the MES supplier for a capability table rather than a presentation. You need concrete answers:

• Does the MES act as an OPC UA Client, or does it require a separate connector?
• Does it support Subscription, queues, subscription transfer, and StatusCode?
• Does it accept PubSub directly, through an MQTT connector, or only through an integration-layer API?
• Which encodings, MQTT versions, QoS levels, topics, and metadata does it understand?
• How does it store source timestamp, quality, sequence number, and event identifier?

MQTT support does not imply OPC UA PubSub support. A generic MQTT connector may accept JSON but fail to recognize the OPC UA NetworkMessage structure, DataSet metadata, and compatibility rules. The reverse mistake also happens: a team buys a PubSub Publisher while the MES only supports Client/Server Data Access.

Check the machine side too. An embedded OPC UA Server may limit sessions, MonitoredItems, and the minimum interval. A Publisher may support UDP UADP only even though the design requires MQTT JSON. A gateway can bridge the gap, but it becomes a separate asset with configuration, updates, redundancy, and certificates.

A hybrid design is usually more honest

A hybrid suits most mixed workshops because it leaves the strengths of each model in the right place. A local integration layer connects to machines as an OPC UA Client, browses the address space, normalizes units and statuses, then publishes a stable production contract for the MES and other consumers.

This design does not require every older controller to become a full PubSub Publisher. It also avoids forcing the MES to maintain hundreds of direct sessions through firewalls. Commands return through a separate Client/Server channel with narrow authorization, acknowledgement, and validation in the PLC. Telemetry and events use PubSub with their own retention and repeat-processing rules.

The cost of a hybrid is real. A gateway adds latency, a failure point, and another configuration model. If it maps NodeId ns=4;s=Counter to quantity, the team must keep the mapping version and change log. After a machine firmware replacement, the old NodeId may point elsewhere or disappear, so an automatic contract check on connection is mandatory.

For a new project, define canonical equipment identifiers, units, source timestamp, StatusCode, schema versions, and idempotency rules before choosing a transport. Then decide where transformation lives: in the CNC, industrial gateway, or integration service. Do not distribute the same mapping across every consumer.

When selecting equipment, EAST CNC can clarify the interfaces available on a particular model and include a communication check in commissioning work. Integration acceptance must still refer to your MES, network design, and tag list because a protocol name does not describe a working exchange.

You do not need a hybrid if one MES reads ten machines, the address spaces are stable, and direct subscriptions pass testing with margin. It will not repair a poor data contract either. An extra broker only distributes ambiguous values to more systems faster.

Acceptance must reproduce a failure

You can make the decision after a short test that measures the working chain and deliberately breaks it. A demonstration of one tag on a test bench proves only that two products exchanged a number once.

1. Select 20 to 50 real fields: fast-changing values, rare states, an alarm, a counter, an output event, and one permitted test command. For each field define type, unit, time source, allowed latency, and behavior when quality is bad.
2. Run Client/Server and PubSub at the same source frequency. Record eventId, sequence number, four timestamps, message size, gaps, duplicates, and processor load on the machine or gateway.
3. Disconnect the network for 30 seconds, then for longer than the configured queue. Restart the client, Publisher, broker, and MES separately. Check which values recovered, which were lost, and whether output was doubled.
4. Add a second and third consumer. For Client/Server, watch session and MonitoredItem growth; for UDP, check multicast on switches; for MQTT, measure broker outbound traffic and queue size.
5. Replace a certificate, revoke credentials, change the DataSet version, and remove one required node. The system should report a clear error instead of continuing with zero in place of an unknown value.

Store results in a CSV with the fields mode,machine,event_id,t_source,t_publish,t_receive,t_commit,bytes,status,duplicate. The same file supports comparison of latency percentiles, network cost, and correctness after recovery. Attach the Subscription or WriterGroup configuration, firmware versions, OPC UA profile, and QoS settings to the acceptance report. Without them, nobody can repeat the test in a year.

Choose Client/Server if the MES needs context, addressed operations, and a direct response from the machine, and the connection count stays within tested limits. Choose PubSub for stable streams to many consumers when the team is ready to own a broker or industrial multicast network and version the DataSet. If you need both sets of properties, separate the flows and keep the fast safety loop inside the machine. The final decision should be explained by failure-test results, not by a technology name in a sales proposal.