In PubSub (Clause 4.1), the participating OPC UA Applications in their roles as Publishers and Subscribers are decoupled, and the number of Subscribers receiving data from a Publisher does not influence the Publisher. When multiple plant historians, SCADA clients, and analytics pipelines poll an embedded controller directly over point-to-point sessions, connection requests are rejected and telemetry collection fails once session or subscription queues saturate.
Related coverage on this site examines packaging line information models, local store-and-forward disk buffering on edge gateways, machine tool telemetry and write boundaries, and plant-to-enterprise layer design across Industrial Connectivity.
| Architectural dimension | Documented specification and operational behavior |
|---|---|
| Core architecture release and scope | The OPC Unified Architecture (UA), released in 2008, is a platform-independent service-oriented architecture that integrates the functionality of the individual OPC Classic specifications. |
| Client-Server service-oriented model | In OPC UA Client-Server communication, the full range of information model access is available via services following the design paradigm of service-oriented architecture (SOA), where a service provider receives requests, processes them, and sends the results back with the response. |
| Single-client vs many-to-many notification | Publish-Subscribe (PubSub) provides an alternative mechanism for data and event notification; while in Client-Server communication each notification is for a single client with guaranteed delivery, PubSub has been optimized for many-to-many configurations. |
| Part fourteen normative release dates | OPC 10000-14 (Part 14: PubSub) Release Version 1.05.06 was published on 2025-10-22, and Release Version 1.04 was published on 2018-02-06. |
| Decoupled publisher and subscriber scaling | In PubSub (Clause 4.1), the participating OPC UA Applications in their roles as Publishers and Subscribers are decoupled, and the number of Subscribers receiving data from a Publisher does not influence the Publisher. |
| Production UDP binary transport role | In Clause 4.2, PubSub with UDP transport and binary-encoded messages may be well-suited in production environments for frequent transmission of small amounts of data. It also allows data exchange in one-to-one and one-to-many configurations. |
| Cloud MQTT and JSON analytics path | In Clause 4.2, using standard messaging protocols like MQTT with JSON data encoding supports the cloud integration path and handling of information in stream and batch analytics systems. |
| Brokerless vs broker-based middleware | In Clause 4.3, OPC UA PubSub supports two Message Oriented Middleware variants: a broker-less form where network infrastructure routes datagram messages like UDP, and a broker-based form where Publishers and Subscribers use protocols like MQTT to communicate with a message Broker. |
| Shared information model configuration | In Clause 4.4, PubSub and Client Server are both based on the OPC UA Information Model, and the PubSub Information Model for configuration (Clause 9) promotes configuring Publishers and Subscribers using the OPC UA Client Server model. |
| Subscription vs PubSub distribution contrast | In Annex C (Informative), Annex C contrasts the Subscription functionality available in the Client Server communication model with the data distribution mechanism of PubSub (referencing OPC 10000-1 for an overview of the Client Server model). |
| Open-source stack support | In open62541 (1.4.14), the Publish/Subscribe (PubSub) extension for OPC UA enables fast and efficient 1:m communication and can be used with broker-based protocols like MQTT and AMQP or brokerless implementations like UDP-Multicasting. |
| End-to-end publisher-to-subscriber security | In OPC Foundation OPC Connect, using OPC UA over MQTT (Part 14) provides end-to-end encryption between the OPC UA publisher and OPC UA subscriber regardless of how many broker hops exist, while retaining OPC UA object encoding and standardized data relationships. |
| Protocol evolution timeline | In ISA InTech (Stefan Hoppe, OPC Foundation), OPC UA started in 2007 with a client-server communication architecture over TCP and HTTPS, launched the publisher-subscribe addition in 2014, and released PubSub v1.04 in February 2018 supporting UDP, MQTT, and AMQP. |
Client-Server session state, service sets, and subscription queues
Takeaway: In Annex C.2, the Client Server Subscription model provides reliable delivery using buffering, acknowledgements, and retransmissions, requiring resources in the Server for each connected Client; resource-constrained Servers limit the number of parallel Client connections, Subscriptions, and MonitoredItems.
In Annex C.2, every Client creates individual Sessions, Subscriptions, and MonitoredItems that are not shared with other Clients. In Clause 5.6.1, a SecureChannel is a long-running logical connection between a single Client and a single Server that maintains a set of keys used to sign and encrypt Messages sent across the network to ensure Confidentiality and Integrity. In Clause 5.6.2.1, Clients should request a new SecurityToken after 75 % of its lifetime has elapsed, and Clients should accept Messages secured by an expired SecurityToken for up to 25 % of the token lifetime. In Clause 5.7.2.1, CreateSession is used by an OPC UA Client to create a Session over an established SecureChannel, and the Server returns two values that uniquely identify the Session, the first of which is the sessionId. In CreateSession (Clause 5.7.2), a Server returns Bad_NonceInvalid if the Client nonce length is less than 32 bytes or greater than 128 bytes. In CreateSession (Clause 5.7.2), a Server returns the status code Bad_TooManySessions when the Server has reached its maximum number of Sessions.
In Clause 5.9.1, Clients use the browse Services of the View Service Set to navigate through the AddressSpace or through a View that is a subset of the AddressSpace. In Clause 5.11.1, the Attribute Service Set provides Services to access Attributes that are part of Nodes, beginning with the Read Service in Clause 5.11.2. In Clause 5.12.2.1, the Call Service is used to call (invoke) a list of Methods and provides for passing input and output arguments to and from a Method; if the Session is terminated, the results of the Method’s execution cannot be returned to the Client and are discarded. In Clause 4.3 of Alarms and Conditions, AcknowledgeableConditions are sub-types of the base ConditionType that expose states related to acknowledged or confirmed in a Condition, where an AckedState and a ConfirmedState extend the EnabledState.
- Monitored item creation parameters: In Clause 5.13.1.1, Clients define MonitoredItems to subscribe to data and Events; each MonitoredItem identifies the item to be monitored and the Subscription to use to send Notifications, and four primary parameters are defined: sampling interval, monitoring mode, filter, and queue parameter.
- Subscription allocation ceiling: In Clause 5.14.2, CreateSubscription returns the status code Bad_TooManySubscriptions when the Server has reached its maximum number of Subscriptions.
- Cyclic notification acknowledgement and keep-alive: In Clause 5.14.5.1, the Publish Service is used for two purposes: to acknowledge the receipt of NotificationMessages for one or more Subscriptions, and to request the Server to return a NotificationMessage or a keep-alive Message.
- Retransmission queue recovery: In Clause 5.14.6.1, the Republish Service requests the Subscription to republish a NotificationMessage from its retransmission queue, returning an error if the requested Message is not in the retransmission queue.
Embedded PLC session limits, sampling intervals, and monitored item budgets
Takeaway: On Siemens S7-1500 OPC UA servers, distributing monitored elements across a large number of subscriptions with a small number of elements (Variant A) requires larger main memory than using a small number of subscriptions with a large number of elements (Variant B).
For Siemens S7-1500 CPUs in firmware V3.1.x, the maximum number of OPC UA sessions is 32 on CPU 1511, 1512, 1513, 48 on CPU 1515, 1516, 1505S, and 64 on CPU 1517, 1518, 1507S. For Siemens S7-1500 CPUs in firmware V3.1.x, the smallest possible sampling interval is 100 ms on CPU 1511, 1512, 1513 and CPU 1515, 1516, 1505S, and 10 ms on CPU 1517, 1518, 1507S. For Siemens S7-1500 CPUs in firmware V3.1.x, the smallest possible Send interval is 200 ms on CPU 1511, 1512, 1513, 100 ms on CPU 1515, 1516, 1505S, and 10 ms on CPU 1517, 1518, 1507S. For Siemens S7-1500 CPUs in firmware V3.1.x, the OPC UA server supports a maximum of 50 subscriptions per session, 20 subscriptions over all sessions with a maximum of 1000 monitored elements, and 10 subscriptions over all sessions with more than 1000 monitored elements. On Siemens S7-1500 OPC UA servers, 10,000 elements per subscription is always the maximum, and exceeding subscription or server quantity frameworks returns BadTooManyMonitoredItems or BadOutOfMemory.
For Siemens S7-1500 CPUs in firmware V3.1.x, the recommended maximum number of monitored elements over all subscriptions (at a 1 second Sampling and Send interval and 50% maximum communication load) is 4000 for CPU 1511, 1511C, 1513, 1505S and CPU 1515, 1516, and 24000 for CPU 1517, 1518, 1507S. For Siemens S7-1500 CPUs in firmware V2.9.x, the maximum number of subscriptions per session is 20, and the smallest possible Send interval is 500 ms on CPU 1510, 1511, 1512, 1513, 200 ms on CPU 1515, 1516, 1505S, and 10 ms on CPU 1517, 1518, 1507S. For Siemens S7-1500 CPUs in firmware V2.9.x, the recommended maximum number of monitored elements over all subscriptions is 1000 for CPU 1510, 1511, 1511C, 1513, 1505S, 2000 for CPU 1515, 1516, and 10000 for CPU 1517, 1518, 1507S. For Siemens S7-1200 CPUs in firmware V4.6, the OPC UA server supports a maximum of 10 sessions, 5 subscriptions per session, 2000 nodes for user-defined server interfaces, and 1000 max monitored elements.
| Controller family and resource parameter | Documented capacity limit and firmware behavior |
|---|---|
| Concurrent session ceiling across CPU tiers | For Siemens S7-1500 CPUs in firmware V3.1.x, the maximum number of OPC UA sessions is 32 on CPU 1511, 1512, 1513, 48 on CPU 1515, 1516, 1505S, and 64 on CPU 1517, 1518, 1507S. |
| Minimum sampling intervals across CPU tiers | For Siemens S7-1500 CPUs in firmware V3.1.x, the smallest possible sampling interval is 100 ms on CPU 1511, 1512, 1513 and CPU 1515, 1516, 1505S, and 10 ms on CPU 1517, 1518, 1507S. |
| Minimum publishing intervals across CPU tiers | For Siemens S7-1500 CPUs in firmware V3.1.x, the smallest possible Send interval is 200 ms on CPU 1511, 1512, 1513, 100 ms on CPU 1515, 1516, 1505S, and 10 ms on CPU 1517, 1518, 1507S. |
| Entry-tier CPU session and interval profile | For Siemens S7-1500 CPU 1511, 1512, 1513 in firmware V3.1.x, the maximum number of OPC UA sessions is 32, the smallest possible sampling interval is 100 ms, and the smallest possible Send interval is 200 ms. |
| Mid-tier CPU session and interval profile | For Siemens S7-1500 CPU 1515, 1516, 1505S in firmware V3.1.x, the maximum number of OPC UA sessions is 48, the smallest possible sampling interval is 100 ms, and the smallest possible Send interval is 100 ms. |
| High-tier CPU session and interval profile | For Siemens S7-1500 CPU 1517, 1518, 1507S in firmware V3.1.x, the maximum number of OPC UA sessions is 64, the smallest possible sampling interval is 10 ms, and the smallest possible Send interval is 10 ms. |
| Subscriptions per session and total server caps | For Siemens S7-1500 CPUs in firmware V3.1.x, the OPC UA server supports a maximum of 50 subscriptions per session, 20 subscriptions over all sessions with a maximum of 1000 monitored elements, and 10 subscriptions over all sessions with more than 1000 monitored elements. |
| Maximum elements per subscription and error codes | On Siemens S7-1500 OPC UA servers, 10,000 elements per subscription is always the maximum, and exceeding subscription or server quantity frameworks returns BadTooManyMonitoredItems or BadOutOfMemory. |
| Subscription memory layout engineering rule | On Siemens S7-1500 OPC UA servers, distributing monitored elements across a large number of subscriptions with a small number of elements (Variant A) requires larger main memory than using a small number of subscriptions with a large number of elements (Variant B). |
| Recommended monitored elements at half load | For Siemens S7-1500 CPUs in firmware V3.1.x, the recommended maximum number of monitored elements over all subscriptions (at a 1 second Sampling and Send interval and 50% maximum communication load) is 4000 for CPU 1511, 1511C, 1513, 1505S and CPU 1515, 1516, and 24000 for CPU 1517, 1518, 1507S. |
| Prior firmware subscription and interval limits | For Siemens S7-1500 CPUs in firmware V2.9.x, the maximum number of subscriptions per session is 20, and the smallest possible Send interval is 500 ms on CPU 1510, 1511, 1512, 1513, 200 ms on CPU 1515, 1516, 1505S, and 10 ms on CPU 1517, 1518, 1507S. |
| Prior firmware recommended monitored elements | For Siemens S7-1500 CPUs in firmware V2.9.x, the recommended maximum number of monitored elements over all subscriptions is 1000 for CPU 1510, 1511, 1511C, 1513, 1505S, 2000 for CPU 1515, 1516, and 10000 for CPU 1517, 1518, 1507S. |
| Compact controller session and node ceilings | For Siemens S7-1200 CPUs in firmware V4.6, the OPC UA server supports a maximum of 10 sessions, 5 subscriptions per session, 2000 nodes for user-defined server interfaces, and 1000 max monitored elements. |
PubSub dataset pipeline, UADP binary headers, and cyclic key frames
Takeaway: In Clause 5.1, each NetworkMessage includes header information (such as identification and security data) and one or more DataSetMessages (the payload), where a DataSetWriter component of a Publisher generates a continuous sequence of DataSetMessages from a DataSet.
In Clause 5.2.1, a PublishedDataSet is similar to either an Event MonitoredItem or a list of data MonitoredItems in the Client Server Subscription model, and a DataSetWriter handles the creation of a DataSetMessage for a DataSet. In Clause 5.4.5.1, a Security Key Service (SKS) provides keys for message security; separate keys are associated with each SecurityGroupId, where GetSecurityKeys receives key material and SetSecurityKeys pushes security keys for a SecurityGroup into a Publisher or Subscriber. In Clause 6.2.4.3, KeyFrameCount (DataType UInt32) is the multiplier of the PublishingInterval that defines the maximum number of times the PublishingInterval expires before a key frame message with values for all published Variables is sent. In Clause 6.2.4.3, delta frame DataSetMessages contain just the changed values (and are not sent if no changes exist), whereas if KeyFrameCount is set to 1, every message contains a key frame. In Clause 6.2.4.3, for cyclic PublishedDataSets KeyFrameCount shall be greater than or equal to 1, and for non-cyclic acyclic event-based DataSets KeyFrameCount shall be 0.
In Clause 6.2.6.2 and 6.2.6.3, PublishingInterval (DataType Duration) defines the interval in milliseconds for publishing NetworkMessages, and KeepAliveTime (DataType Duration) defines the time in milliseconds until the Publisher sends a keep-alive DataSetMessage. In Clause 6.2.6.4 and 6.2.6.6, WriterGroup Priority (DataType Byte) ranges from 0 (lowest) to 255 (highest), and HeaderLayoutUri (DataType String) selects a well-defined configuration for a subset of PubSub communication parameters. In Clause 6.2.9.6, MessageReceiveTimeout is the maximum acceptable time between two DataSetMessages; if no new DataSetMessage (including keep-alive and heartbeat messages) is received within this period, the DataSetReader State transitions to Error. In Clause 7.2.4.5, UADPVersion occupies bits 0-3 of the UADP NetworkMessage header and is set to 1 for this specification version, while UADPFlags occupy bits 4-7. In the UADP GroupHeader (Clause 7.2.4.5), Bit 0 enables WriterGroupId (UInt16), Bit 1 enables GroupVersion, Bit 2 enables NetworkMessageNumber, and Bit 3 enables SequenceNumber (UInt16). In the UADP ExtendedNetworkMessageHeader and SecurityHeader (Clause 7.2.4.5), PicoSeconds (UInt16) specifies the number of 10 picosecond intervals added to Timestamp, and SecurityHeader carries SecurityFlags and SecurityTokenId. In Clause 7.2.4.4.3.2, UADP message encryption and decryption with AES-CTR mode uses an EncryptingKey and a counter block whose SecurityHeader Nonce length shall be 8 Bytes and BlockCounter is a 4-Byte 32-bit big-endian integer starting at 1.
| PubSub configuration or header element | Normative definition and encoding rule |
|---|---|
| Key frame multiplier definition | In Clause 6.2.4.3, KeyFrameCount (DataType UInt32) is the multiplier of the PublishingInterval that defines the maximum number of times the PublishingInterval expires before a key frame message with values for all published Variables is sent. |
| Delta frame vs full key frame emission | In Clause 6.2.4.3, delta frame DataSetMessages contain just the changed values (and are not sent if no changes exist), whereas if KeyFrameCount is set to 1, every message contains a key frame. |
| Cyclic vs acyclic dataset counter rule | In Clause 6.2.4.3, for cyclic PublishedDataSets KeyFrameCount shall be greater than or equal to 1, and for non-cyclic acyclic event-based DataSets KeyFrameCount shall be 0. |
| Publishing interval and keep-alive timer | In Clause 6.2.6.2 and 6.2.6.3, PublishingInterval (DataType Duration) defines the interval in milliseconds for publishing NetworkMessages, and KeepAliveTime (DataType Duration) defines the time in milliseconds until the Publisher sends a keep-alive DataSetMessage. |
| WriterGroup priority and header layout URI | In Clause 6.2.6.4 and 6.2.6.6, WriterGroup Priority (DataType Byte) ranges from 0 (lowest) to 255 (highest), and HeaderLayoutUri (DataType String) selects a well-defined configuration for a subset of PubSub communication parameters. |
| DataSetReader receive timeout transition | In Clause 6.2.9.6, MessageReceiveTimeout is the maximum acceptable time between two DataSetMessages; if no new DataSetMessage (including keep-alive and heartbeat messages) is received within this period, the DataSetReader State transitions to Error. |
| UADP version and header flags bitfield | In Clause 7.2.4.5, UADPVersion occupies bits 0-3 of the UADP NetworkMessage header and is set to 1 for this specification version, while UADPFlags occupy bits 4-7. |
| UADP GroupHeader identifier and sequence bits | In the UADP GroupHeader (Clause 7.2.4.5), Bit 0 enables WriterGroupId (UInt16), Bit 1 enables GroupVersion, Bit 2 enables NetworkMessageNumber, and Bit 3 enables SequenceNumber (UInt16). |
| UADP picosecond resolution and security header | In the UADP ExtendedNetworkMessageHeader and SecurityHeader (Clause 7.2.4.5), PicoSeconds (UInt16) specifies the number of 10 picosecond intervals added to Timestamp, and SecurityHeader carries SecurityFlags and SecurityTokenId. |
| UADP AES-CTR nonce and block counter format | In Clause 7.2.4.4.3.2, UADP message encryption and decryption with AES-CTR mode uses an EncryptingKey and a counter block whose SecurityHeader Nonce length shall be 8 Bytes and BlockCounter is a 4-Byte 32-bit big-endian integer starting at 1. |
Brokerless UDP multicast, raw Ethernet TSN frames, and brokered MQTT transport
Takeaway: In Clause 4.3, OPC UA PubSub supports two Message Oriented Middleware variants: a broker-less form where network infrastructure routes datagram messages like UDP, and a broker-based form where Publishers and Subscribers use protocols like MQTT to communicate with a message Broker.
For OPC UA UDP (Clause 7.3.2.1), the MaxNetworkMessageSize that fits into 1 MTU is maximum 1472 Byte for IPv4 and 1452 Byte for IPv6, and MaxNetworkMessageSize plus additional headers shall be limited to 65535 Byte. For OPC UA UDP discovery (Clause 7.3.2), the IANA-registered IPv4 multicast address is 224.0.2.14, the recommended port is 4840, and the default DiscoveryMaxMessageSize for UDP is 4096 bytes. For OPC UA UDP multicast (Clause 7.3.2.2), it is recommended to use network switches with IGMP (IETF RFC 1112 for V1, RFC 2236 for V2, RFC 3376 for V3) and MLD (RFC 4604 for MLD V2) support to limit multicast traffic distribution. For OPC UA PubSub over DTLS (Clause 7.3.2.4), the IANA-registered port is 4843, and the DTLS transport does not support multicast of PubSub and can only be used for unicast communication. For OPC UA Ethernet (Clause 7.3.3), the IANA-registered EtherType for UADP communication is 0xB62C with URL syntax opc.eth://<host>[:<VID>[.PCP]] and a frame size of 1522 Byte (typically 1500 Byte MaxNetworkMessageSize plus 22 Byte headers including a 4 Byte IEEE Std 802.3-2018 VLAN tag).
For the OPC UA MQTT transport mapping (Clause 7.3.4), two versions of MQTT are supported (version 3.1.1 and version 5.0) with both binary-encoded and JSON-encoded DataSetMessages, using default ports 8883 for mqtts, 1883 for mqtt, and 443 for wss. In Clause 7.3.4.5, BrokerTransportQualityOfService maps AtMostOnce and BestEffort to MQTT QoS 0, AtLeastOnce to MQTT QoS 1, and ExactlyOnce to MQTT QoS 2. In Clause 7.3.4.7.1, the general OPC UA MQTT Topic pattern is <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/[<WriterGroup>[/<DataSetWriter>]], where the default <Prefix> value is ‘opcua’ and <Encoding> is ‘json’ or ‘uadp’. In Annex B.2 and B.3, OPC UA PubSub defines non-normative broker transport mappings for Kafka and AMQP, with AMQP default ports 5671 for amqps, 5672 for amqp, and 443 for wss. In Clause 7.2.5.2 Table 183, JSON NetworkMessage MessageTypes map DataSetMessage to ua-data, DataSetMetaData to ua-metadata, ApplicationDescription to ua-application, ServerEndpoints to ua-endpoints, and Status to ua-status.
- Single-MTU UDP datagram sizing: For OPC UA UDP (Clause 7.3.2.1), the MaxNetworkMessageSize that fits into 1 MTU is maximum 1472 Byte for IPv4 and 1452 Byte for IPv6, and MaxNetworkMessageSize plus additional headers shall be limited to 65535 Byte.
- Multicast discovery address and size cap: For OPC UA UDP discovery (Clause 7.3.2), the IANA-registered IPv4 multicast address is 224.0.2.14, the recommended port is 4840, and the default DiscoveryMaxMessageSize for UDP is 4096 bytes.
- Managed switch IGMP and MLD snooping standards: For OPC UA UDP multicast (Clause 7.3.2.2), it is recommended to use network switches with IGMP (IETF RFC 1112 for V1, RFC 2236 for V2, RFC 3376 for V3) and MLD (RFC 4604 for MLD V2) support to limit multicast traffic distribution.
- DTLS unicast transport constraint: For OPC UA PubSub over DTLS (Clause 7.3.2.4), the IANA-registered port is 4843, and the DTLS transport does not support multicast of PubSub and can only be used for unicast communication.
- Raw Ethernet EtherType and VLAN priority tagging: For OPC UA Ethernet (Clause 7.3.3), the IANA-registered EtherType for UADP communication is 0xB62C with URL syntax opc.eth://<host>[:<VID>[.PCP]] and a frame size of 1522 Byte (typically 1500 Byte MaxNetworkMessageSize plus 22 Byte headers including a 4 Byte IEEE Std 802.3-2018 VLAN tag).
- MQTT protocol versions and transport ports: For the OPC UA MQTT transport mapping (Clause 7.3.4), two versions of MQTT are supported (version 3.1.1 and version 5.0) with both binary-encoded and JSON-encoded DataSetMessages, using default ports 8883 for mqtts, 1883 for mqtt, and 443 for wss.
- Broker delivery quality of service mapping: In Clause 7.3.4.5, BrokerTransportQualityOfService maps AtMostOnce and BestEffort to MQTT QoS 0, AtLeastOnce to MQTT QoS 1, and ExactlyOnce to MQTT QoS 2.
- Standard MQTT topic hierarchy and encoding tokens: In Clause 7.3.4.7.1, the general OPC UA MQTT Topic pattern is <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/[<WriterGroup>[/<DataSetWriter>]], where the default <Prefix> value is ‘opcua’ and <Encoding> is ‘json’ or ‘uadp’.
- JSON NetworkMessage types and metadata separation: In Clause 7.2.5.2 Table 183, JSON NetworkMessage MessageTypes map DataSetMessage to ua-data, DataSetMetaData to ua-metadata, ApplicationDescription to ua-application, ServerEndpoints to ua-endpoints, and Status to ua-status.
- Enterprise Kafka and AMQP broker mappings: In Annex B.2 and B.3, OPC UA PubSub defines non-normative broker transport mappings for Kafka and AMQP, with AMQP default ports 5671 for amqps, 5672 for amqp, and 443 for wss.
Architecture selection checklist for industrial telemetry and command boundaries
Takeaway: In Clause 5.12.2.1, the Call Service is used to call (invoke) a list of Methods and provides for passing input and output arguments to and from a Method; if the Session is terminated, the results of the Method’s execution cannot be returned to the Client and are discarded.
Isolating the root cause of controller session exhaustion prevents unplanned polling drop-offs when scaling plant telemetry across multiple downstream consumers. In OPC UA Client-Server communication, the full range of information model access is available via services following the design paradigm of service-oriented architecture (SOA), where a service provider receives requests, processes them, and sends the results back with the response. In Clause 4.2, PubSub with UDP transport and binary-encoded messages may be well-suited in production environments for frequent transmission of small amounts of data. It also allows data exchange in one-to-one and one-to-many configurations. In Clause 4.3 of Alarms and Conditions, AcknowledgeableConditions are sub-types of the base ConditionType that expose states related to acknowledged or confirmed in a Condition, where an AckedState and a ConfirmedState extend the EnabledState. In Clause 5.14.6.1, the Republish Service requests the Subscription to republish a NotificationMessage from its retransmission queue, returning an error if the requested Message is not in the retransmission queue.
| Verification checkpoint | Engineering criterion to confirm before deployment |
|---|---|
| Synchronous method and recipe execution | In Clause 5.12.2.1, the Call Service is used to call (invoke) a list of Methods and provides for passing input and output arguments to and from a Method; if the Session is terminated, the results of the Method’s execution cannot be returned to the Client and are discarded. |
| Stateful alarm acknowledgment and confirmation | In Clause 4.3 of Alarms and Conditions, AcknowledgeableConditions are sub-types of the base ConditionType that expose states related to acknowledged or confirmed in a Condition, where an AckedState and a ConfirmedState extend the EnabledState. |
| Controller subscription memory layout | On Siemens S7-1500 OPC UA servers, distributing monitored elements across a large number of subscriptions with a small number of elements (Variant A) requires larger main memory than using a small number of subscriptions with a large number of elements (Variant B). |
| Sequence retransmission vs receive timeout | In Clause 5.14.6.1, the Republish Service requests the Subscription to republish a NotificationMessage from its retransmission queue, returning an error if the requested Message is not in the retransmission queue. |
| Single-MTU UDP datagram sizing | For OPC UA UDP (Clause 7.3.2.1), the MaxNetworkMessageSize that fits into 1 MTU is maximum 1472 Byte for IPv4 and 1452 Byte for IPv6, and MaxNetworkMessageSize plus additional headers shall be limited to 65535 Byte. |
| Managed switch multicast pruning | For OPC UA UDP multicast (Clause 7.3.2.2), it is recommended to use network switches with IGMP (IETF RFC 1112 for V1, RFC 2236 for V2, RFC 3376 for V3) and MLD (RFC 4604 for MLD V2) support to limit multicast traffic distribution. |
| MQTT topic namespace and encoding | In Clause 7.3.4.7.1, the general OPC UA MQTT Topic pattern is <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/[<WriterGroup>[/<DataSetWriter>]], where the default <Prefix> value is ‘opcua’ and <Encoding> is ‘json’ or ‘uadp’. |
Sources
- OPC Foundation — Unified Architecture Specification Services and PubSub Reference Documentation
- Siemens Industry Online Support — SIMATIC Controller OPC UA Server Function Manual and Technical Specifications
- open62541 Project — Open-Source C Implementation Documentation for OPC UA Client-Server and PubSub
