Content
# #ccsd-water-ignition — 2025-09-03
**12:03 [andy](https://slack.com/archives/C08TVA84PD4/p1756926218810839):** I just noticed that in Studio V36 it can do *Embedded OPC UA:* A major highlight is the integration of an OPC UA (Open Platform Communications Unified Architecture) server and client directly at the controller level for ControlLogix 5580 and CompactLogix 5380 controllers. This facilitates seamless data exchange with third-party devices and enterprise systems without the need for intermediate gateways.
Gemeni spit this out:
When communicating with remote Opto 22 controllers over a restricted network where limiting traffic is your main concern, *OPC UA is generally the superior choice over both implicit and explicit messaging.* It provides more sophisticated tools to control data flow and reduce network chatter.
Here’s a breakdown comparing the three, focusing on your use case of preventing traffic flooding.
*Implicit Messaging (like EtherNet/IP I/O)*
Implicit messaging is designed for real-time, high-speed I/O control. It works like a scheduled delivery service.
• *How it works:* Data is sent continuously and cyclically at a fixed rate, known as the Requested Packet Interval (RPI). The controller and the remote device are in a persistent connection, constantly exchanging a predefined block of data.
• *Traffic Pattern:* This method is the *"chattiest"* by far. It generates constant, predictable traffic regardless of whether the data has changed or not. Think of it as a security camera streaming video 24/7, even if there's no motion.
• *Use Case:* Best for local, high-speed machine control where deterministic updates are critical (e.g., controlling a servo motor).
• *For your restricted network:* This is the *worst option*. The continuous stream of data packets, even when values are static, will quickly flood a low-bandwidth network.
*Explicit Messaging (like CIP)*
Explicit messaging is a query-based system. It works like sending an email and waiting for a reply.
• *How it works:* The client sends a specific request (e.g., "Give me the value of this temperature sensor") to the server, which then processes the request and sends back a response. Each transaction is a distinct, two-way communication event.
• *Traffic Pattern:* Traffic is generated *only when a request is made*. This is far more efficient than implicit messaging if you only need data intermittently. However, it has a higher overhead per transaction because each message contains all the addressing and instruction information needed for that specific request.
• *Use Case:* Good for non-time-critical tasks like reading diagnostic information, changing a configuration parameter, or retrieving a value on an HMI that doesn't need constant updates.
•
•
• *For your restricted network:* This is a *viable but not optimal* choice. While it avoids constant traffic, you could still flood the network if you need to poll for data changes frequently. If you have many devices all making requests, the network can become congested with request/response packets.
*OPC UA (Unified Architecture)*
OPC UA is a modern, secure, and highly flexible communication framework. It offers different models of communication, giving you the tools to tailor it to your network's limitations.
• *How it works:* OPC UA primarily uses a *publish/subscribe (Pub/Sub)* model or a *client/server* model. The key is its "report by exception" capability.
•
•
◦ *Client/Server with Subscriptions:* The client subscribes to data nodes on the server (the Opto 22 controller). The server is then responsible for monitoring the data. It only sends an update to the client when the value *changes* or exceeds a defined "deadband" (e.g., only report a temperature change of more than 0.5 degrees).
◦ *Publish/Subscribe:* For even greater efficiency, a publisher sends data to the network, and any subscriber can receive it without a direct connection. This is a one-to-many model that is extremely efficient for broadcasting data.
• *Traffic Pattern:* This is the *most efficient* method for a restricted network. You establish a subscription once, and then traffic is only generated when the data is meaningful. This "report by exception" model means a static system generates almost no traffic.
• *Use Case:* Ideal for SCADA, MES, and cloud integration, and especially for communication over bandwidth-constrained networks like cellular or satellite.
• *For your restricted network:* This is the *best option*. By configuring subscriptions with appropriate deadbands, you ensure that only necessary data traverses the network. This prevents flooding by design and provides secure, reliable communication.
*Comparison Summary*
FeatureImplicit MessagingExplicit MessagingOPC UA*Traffic PatternConstant & CyclicOn-Demand (Request/Response)On-Change (Report by Exception)Network Friendliness*:x: *Very Poor* (Floods network):heavy_check_mark: *Good* (Better than implicit):white_check_mark: *Excellent* (Most efficient)*Overhead*Low per packetHigh per transactionModerate, but highly configurable*Best For*High-speed, local I/ONon-critical data reads/writesRemote monitoring over any network
*Conclusion:*
For your use case with remote Opto 22 controllers on a restricted network, *OPC UA is the clear winner.* Its ability to report by exception using subscriptions allows you to get the data you need without the constant chatter of implicit messaging or the repetitive polling that might be required with explicit messaging. This will give you the most control over network traffic and prevent flooding.
**12:03 [andy](https://slack.com/archives/C08TVA84PD4/p1756926237563539):** Is this actually a good choice?
**13:38 [Kevin](https://slack.com/archives/C08TVA84PD4/p1756931888461279):** Report by exception can be a pain.
Mason had a hundred or so CIP nodes on an older wireless network at the oil field and never had an issue. Plus we know how to use it. Happy to explore the OPC UA thing if you want.
**13:41 [Kevin](https://slack.com/archives/C08TVA84PD4/p1756932085732979):** I also wonder if we setup OPC in the opto then what do we do when you change to all AB?
**13:54 [andy](https://slack.com/archives/C08TVA84PD4/p1756932867892479):** Right. Yeah, we are heading to AB and explicit messaging should be lightweight enough.