OPC UA PubSub over UDP: Prove the Packet Path Before You Trust a Single Tag

PubSub isn't a client session — stop debugging it like one

A subscriber HMI shows a motor running at 47 degC, updating smoothly on screen. The publisher gateway has been powered off for six minutes. Nobody noticed, because a last-value display fed by UDP PubSub has no session to drop. It just keeps repainting the last datagram it decoded.

That is the trap with OPC UA PubSub. Under the spec (OPC UA Part 14, UADP messages over UDP) a publisher sprays DataSetMessages onto the network and any subscriber decodes them — no session keepalive, no browse step, no per-client subscription state on the source. The low overhead is exactly why you reach for it when several consumers need the same live data. It is also why the familiar troubleshooting instincts fail.

When a value is wrong or missing there is no session error to point at. The cause could be publisher configuration, dataset field order, multicast filtering, VLAN routing, a subscriber firewall, clock drift, or a decode mismatch. Commission it like an industrial network interface, not like an OPC UA client: prove the packet path, the message schema, and the data meaning as three separate steps, in that order.

Freeze the dataset contract before any consumer connects

A PubSub subscriber usually depends on a fixed dataset definition. If the publisher changes field order, field names, data types, or metadata version, a subscriber may continue receiving UDP packets while silently mapping values to the wrong tags.

Record the dataset contract in a small table:

Item	Example	Why it matters
PublisherId	Line3GatewayA	Separates one source from another on the same network.
WriterGroupId / DataSetWriterId	10 / 2	Used by subscribers to select the right stream.
Dataset name	Line3.PackML.Status	Human-readable commissioning reference.
Field order	State, Mode, GoodCount, RejectCount	Prevents shifted tag mapping.
Data type and engineering unit	UInt16, Int32, degC, bar	Prevents display and historian errors.
Metadata version	2026-06-29.1	Lets consumers reject unknown layouts.

Do not rely only on screenshots from the publisher tool. Export the configuration or keep it in version control when the platform allows it.

Most PubSub faults are network faults in an OPC UA costume

Most UDP PubSub problems I have chased on site turned out to be network problems wearing an OPC UA name. The publisher was sending correctly; the subscriber sat on a VLAN where multicast was blocked, or where IGMP snooping with no active querier had pruned the group and the switch quietly stopped forwarding it. UADP over UDP typically runs as multicast, so this is the failure mode to expect first, not last.

Check these before you touch the application:

• multicast group address and UDP port;
• source interface selected by the publisher;
• subscriber interface and route table;
• VLAN membership on publisher, switches, and subscribers;
• IGMP snooping and querier configuration;
• firewall rules for inbound UDP on the subscriber;
• whether the switch mirrors or blocks the traffic during capture;
• storm-control limits that may drop bursts.

For a first test, capture at the publisher port and at one subscriber port. If packets leave the publisher but never arrive at the subscriber, stay in the network layer. If packets arrive but values do not update, move to dataset decoding.

A packet capture proves frames exist, not that they were accepted

Packet capture tells you that UDP frames exist. It does not prove the subscriber accepted them. A subscriber diagnostic view should show at least:

• last message receive time;
• sequence number or message counter;
• dropped or out-of-order message count;
• metadata mismatch count;
• decode errors by field;
• current publisher state if available;
• last good value timestamp per dataset.

During commissioning, leave a temporary diagnostic screen or log enabled. It should be clear whether the subscriber is seeing no packets, rejecting packets, or accepting packets with bad quality.

A common failure is to show stale values as if they are live. Every subscribed dataset needs an age check. If no message arrives within the allowed interval, set quality bad or stale and make the HMI show it.

Define timing in process terms, not packet rate

PubSub is often chosen for fast distribution, but the useful target is not the packet rate. Define what the process actually needs.

Useful timing values:

• publishing interval;
• maximum acceptable message age at the HMI;
• allowed packet loss before quality changes;
• subscriber timeout;
• clock tolerance between publisher and subscriber;
• historian sample behavior if PubSub feeds storage;
• restart recovery time after publisher reboot.

For example, a 100 ms publisher interval does not guarantee a 100 ms operator response. The HMI scan, screen refresh, subscriber queue, and bad-quality timeout all add behavior. Measure the chain with timestamps rather than assuming the configured publish interval is the final performance.

Don't let last-value displays hide UDP loss

UDP can lose packets. That may be acceptable for fast status distribution, but it is not acceptable to hide the loss.

Use explicit rules:

• A missed packet count of one or two may be tolerated for fast analog display.
• A stale dataset should turn quality bad after a defined timeout.
• Command feedback and permissive states should not depend only on a lossy one-way stream unless a safer confirmation path exists.
• Alarms should be designed carefully if PubSub is the source. A missed transient may matter.
• Historian ingestion needs source timestamps and quality so gaps are visible later.

If the process requires guaranteed delivery of every event, PubSub over UDP alone is probably the wrong mechanism. Use it for live distribution where the system can tolerate and detect loss.

Field mistakes that still decode cleanly

Dataset mapping mistakes are easy to miss because the packet still decodes.

Common examples:

Symptom	Likely cause	Field check
Motor state shows impossible number	Enum mapping changed	Compare enum list, not only integer type.
Temperature is scaled by 10	Publisher changed engineering scaling	Check raw value, unit, and display scaling.
Good count appears as reject count	Field order shifted	Compare dataset metadata version and field order.
Subscriber rejects all messages after update	Metadata version or namespace mismatch	Inspect subscriber decode log.
Values freeze after switch replacement	Multicast or IGMP behavior changed	Capture on both switch sides.
One subscriber works and another does not	Local firewall or NIC route	Check inbound UDP and selected interface.

Make one known-value test. Force a safe simulated value at the source, confirm the exact field at the subscriber, then remove the simulation. Bulk tag import should happen after this proof, not before it.

Test restart and network recovery deliberately

A clean startup is part of the interface, not a given. Test it on purpose.

1. Start the subscriber before the publisher and confirm it reports waiting, not normal stale data.
2. Start the publisher and measure time to first good dataset.
3. Restart the publisher while the subscriber stays online.
4. Pull the subscriber network path for a short controlled interval.
5. Restore the network and confirm sequence counters, stale flags, and HMI quality recover.
6. Change metadata in a test environment and confirm the subscriber rejects unknown layouts or reports the version clearly.

Do not accept a test that only shows values changing on a normal day. PubSub issues usually appear during reboot, switch maintenance, VLAN changes, or gateway replacement.

The handover pack

For each PubSub stream, keep these items with the project documentation:

• publisher host, interface, multicast address, and UDP port;
• WriterGroupId, DataSetWriterId, dataset name, and metadata version;
• field list with data types, units, and enum definitions;
• expected publishing interval and subscriber timeout;
• switch and VLAN notes, including IGMP settings;
• packet capture from a known-good test;
• subscriber diagnostic screenshot or log;
• restart and network recovery test result.

This is enough for the next engineer to separate network loss from schema mismatch without rediscovering the whole interface during a production outage.