Traffic-Aware Configuration of OPC UA PubSub in Industrial Automation Networks

Interoperability across industrial automation systems is a cornerstone of Industry 4.0. To address this need, the OPC Unified Architecture (OPC UA) Publish-Subscribe (PubSub) model offers a promising mechanism for enabling efficient communication among heterogeneous devices. PubSub facilitates resource sharing and communication configuration between devices, but it lacks clear guidelines for mapping diverse industrial traffic types to appropriate PubSub configurations. This gap can lead to misconfigurations that degrade network performance and compromise real-time requirements. This paper proposes a set of guidelines for mapping industrial traffic types, based on their timing and quality-of-service specifications, to OPC UA PubSub configurations. The goal is to ensure predictable communication and support real-time performance in industrial networks. The proposed guidelines are evaluated through an industrial use case that demonstrates the impact of incorrect configuration on latency and throughput. The results underline the importance of traffic-aware PubSub configuration for achieving interoperability in Industry 4.0 systems.

💡 Research Summary

The paper addresses a critical gap in the application of the OPC Unified Architecture Publish‑Subscribe (OPC UA PubSub) model within industrial automation networks: the lack of concrete guidance for mapping diverse traffic types to appropriate PubSub configuration parameters. While OPC UA PubSub offers a scalable, decoupled communication paradigm that overcomes the real‑time limitations of the traditional client‑server model, the OPC UA specification (Part 14) does not prescribe how to translate the timing, criticality, loss‑tolerance, and size‑consistency requirements of industrial traffic into concrete PubSub settings such as DSMType, PublishingInterval, KeyFrameCount, DatasetOrdering, or TransportProfileUri. This omission can lead to misconfigurations that degrade latency, throughput, and determinism—issues that are unacceptable for control‑loop or safety‑critical applications.

The authors first provide a concise overview of the PubSub message‑generation pipeline. Data is selected from the address space into PublishedDataSets (PDS), assembled into DataSetMessages (DSM) by a DataSetWriter, aggregated by a WriterGroup into NetworkMessages (NM), and finally transmitted according to the PubSubConnection’s transport profile (e.g., UDP‑based UADP or broker‑based MQTT/AMQP). They enumerate the four primary DSM types—Key Frame, Delta Frame, Event, and Keep‑Alive—along with the configuration knobs that control their behavior: CyclicDataset (boolean), DSMType, KeyFrameCount, PublishingInterval, DatasetOrdering (Undefined, AscendingWriterID, AscendingWriterIDSingle), MaxNetworkMessageSize, EncodingMimeType, and KeepAliveTime.

To bridge the gap, the paper adopts the 5G‑Alliance for Connected Industries and Automation (5G‑A‑CIA) taxonomy, which defines 13 industrial traffic classes (Control‑Iso, Control‑Sync, Control‑Async, Event, Voice/Video, Command‑Cycle, Command‑Acycle, Config, Diagnostic‑Cycle, Diagnostic‑Acycle, Best‑Effort, etc.) and annotates each class with five attributes: periodicity, criticality, loss tolerance, length consistency, and communication level (C2C, C2D, D2Cmp). By aligning these attributes with PubSub parameters, the authors derive a set of practical configuration guidelines:

1. Cyclic (periodic) control traffic – Set CyclicDataset = true, DSMType = KeyFrame, and choose PublishingInterval equal to the traffic’s cycle time. Use DatasetOrdering = AscendingWriterID to pack multiple DSMs into a single NM while respecting MaxNetworkMessageSize. KeepAliveTime should be ≥ PublishingInterval to guarantee liveness when a key frame is missed.

2. Event‑driven traffic – Set CyclicDataset = false, DSMType = Event. PublishingInterval becomes irrelevant; messages are emitted only on state changes. KeepAlive may still be used for heartbeat purposes.

3. Delta‑frame usage – Recommended only for cyclic data where occasional packet loss is tolerable (e.g., non‑control monitoring). Define KeyFrameCount > 1 so that a full key frame is transmitted after a configurable number of delta frames, preventing subscriber desynchronization. Delta frames are unsuitable for control loops, safety messages, or media streams because loss of a delta frame can corrupt subsequent data.

4. Media (voice/video) traffic – The authors advise against both key and delta frames for continuous streams. Instead, they propose using “chunk” messages (a sequence of NM fragments) that allow out‑of‑order reception and reconstruction, mitigating the impact of packet loss.

5. Keep‑Alive messages – Should be enabled for any cyclic traffic (including delta‑frame streams) to assure that subscribers detect a silent publisher. KeepAliveTime must be set no smaller than the PublishingInterval.

The paper also surveys the open‑source OPC UA stack open62541, exposing mismatches between the specification and the implementation (e.g., missing support for EnableDeltaFrames at the server level, default values for DatasetOrdering). These gaps are summarized in a table, alerting developers to potential pitfalls when relying on the stack out‑of‑the‑box.

To validate the guidelines, the authors construct an industrial use‑case involving a mixed set of traffic classes (high‑priority control loops, periodic diagnostics, and video surveillance). Two configurations are compared: (a) a “naïve” configuration that indiscriminately applies delta frames to all traffic, and (b) the traffic‑aware configuration derived from the guidelines. Empirical measurements reveal that the naïve setup suffers from up to 300 % increase in end‑to‑end latency for control traffic and a 40 % reduction in overall throughput, primarily due to missed key frames and the ensuing need for resynchronization. In contrast, the guideline‑based configuration maintains sub‑millisecond latency for control traffic, deterministic delivery for diagnostics, and acceptable bandwidth usage for video streams.

In conclusion, the authors demonstrate that a systematic, traffic‑aware mapping of industrial communication requirements to OPC UA PubSub parameters is essential for achieving the deterministic, real‑time performance demanded by Industry 4.0 applications. Their guidelines enable system architects to exploit the flexibility of PubSub while preserving the hard real‑time guarantees offered by Time‑Sensitive Networking (TSN). Future work is suggested in the areas of automated subscriber configuration, dynamic adaptation of PubSub parameters at runtime, and extending the approach to more complex media‑rich scenarios.