Integration · PLC

Connect OPC UA to Rockwell / Allen-Bradley via gateway

ProductRockwell / Allen-Bradley via gateway
CategoryPLC
OPC UA roleGateway

ControlLogix and CompactLogix controllers have historically had no native OPC UA server, so the standard pattern is a gateway that speaks EtherNet/IP to the PLC and OPC UA to your client. Newer Rockwell platforms and product lines have added native OPC UA, so confirm your controller's current capability with Rockwell before buying a gateway.

Before you start

  • A decision on whether you actually need a gateway. Capability has changed across recent Rockwell platforms and product lines, so check what your specific controller and firmware can do before designing around a gateway.
  • A gateway product and its licence, sized by tag count or by connected device count depending on the product. Tag-count tiers are the usual commercial trap.
  • A host to run the gateway on, with network reachability to the PLC on the industrial side and to your client on the other, plus a decision about whether it sits inside or outside the cell firewall.
  • The controller tag list, ideally exported from the Studio 5000 project rather than discovered by browsing, so you integrate against a reviewed set of tags.
  • Spare controller connection capacity. The gateway consumes CIP connections like any other client.

Setting it up

  1. Confirm the controller's native capability firstAsk Rockwell what your controller family and firmware support natively. If a native server exists and is licensed for your platform, you remove an entire hop, a licence and a failure domain. Do this before evaluating gateways, not after.
  2. Choose where the gateway sits in the networkThe gateway is the only component that touches both networks, so its placement is the security design. Put it where the cell firewall can allow EtherNet/IP inbound to the PLC and OPC UA outbound or inbound as your policy dictates, and consider reverse connect if the layer boundary only permits outbound sessions.
  3. Configure the PLC channel and deviceDefine the controller as a device on an EtherNet/IP or CIP channel with its IP address and, where the product requires it, slot or path information. Prove the gateway can read one tag before you import hundreds.
  4. Import the tag list rather than typing itImport from a Studio 5000 export or let the gateway browse the controller, then prune to the tags you actually need. Every tag you import is scan load on the gateway and a candidate monitored item on the OPC UA side.
  5. Set scan rates deliberately per tag groupGroup tags by the rate they genuinely need. Counters and state words may need a fast group, temperatures a slow one. The gateway's scan rate, not your OPC UA sampling interval, is the real resolution of the data, and this is the single most misunderstood number in the whole architecture.
  6. Configure the OPC UA server side and its certificatesEnable the gateway's OPC UA endpoint, choose security policies and modes, and complete the trust exchange with your client in both directions. The gateway holds two identities in effect, and only the OPC UA one has a certificate.
  7. Verify end to end with an independent client, then force a failureBrowse and read with UaExpert or opcua-commander, then deliberately pull the PLC's network cable and watch what your client receives. A well-behaved gateway reports the loss as a Bad status on the affected items; a poorly configured one holds the last value and tells you nothing, which will corrupt any downtime calculation built on it.

What the address space looks like

A gateway address space is a flat or lightly foldered tag list, not an information model. Nodes correspond to controller tags, typically with string identifiers derived from the tag name, and user-defined types are usually flattened into member paths or presented as folders of scalars. There is no machine identity, no state machine, no standard counter and no companion-specification content, because a gateway can only republish what CIP exposes. That has two consequences worth planning for: the semantic mapping from tags to meaning lives in your client or your analytics platform, and it must be redone for every controller program you integrate. If you need portability across a mixed fleet, the modelling has to happen somewhere above the gateway.

The traps

  • The historical absence of a native server is the well-known part; the risk now is the opposite error, buying a gateway you no longer need or assuming a native server your firmware does not have. Confirm the current position with Rockwell for your exact controller and firmware.
  • Timestamps come from the gateway, not from the controller. SourceTimestamp is when the gateway completed its poll, so downtime and cycle timing are quantised to the scan rate and skewed by it. If you need millisecond event timing, timestamp it in the PLC and publish that value as data.
  • A gateway will happily serve a stale value as Good if it is configured to hold last known values on a communication loss. Check that behaviour explicitly and prefer a configuration that surfaces the loss as a Bad status, then handle it in your client.
  • Licence tiers are usually counted in tags or devices, and the count you need grows quietly as the project scope grows. Confirm how your product counts and where the tier boundaries are before you import the whole controller.
  • The gateway is a new single point of failure and a new thing to patch, back up and monitor. Its configuration is project data: put it in version control and know how to rebuild it.
  • Controller connection capacity is finite. A gateway plus a historian plus an HMI plus a laptop can exhaust CIP connections and produce intermittent read failures that look like a network fault.
  • Reconfiguring channels or reimporting tags can renumber the gateway's namespaces and rename nodes, so clients holding raw indexes break with BadNodeIdUnknown after routine maintenance.
  • Certificate trust on the OPC UA side remains the biggest deployment hurdle, and it must be done on both the gateway and the client.

Getting OEE data out of it

You can get counts, a state signal and reason codes from a Rockwell controller through a gateway, but the honest boundary is time resolution. Because the gateway timestamps at poll completion, availability computed from a sampled running bit will miss stops shorter than the scan interval and will attribute the rest imprecisely. The fix is in the PLC: maintain good and reject counters, maintain a state or reason word, and where downtime accuracy matters, record the transition timestamp in the controller and publish it as a value your client reads. Nothing here is standardised, so the mapping from tags to OEE meaning is per program and must be documented as project data. Planned production time, shift calendars, order context and standard cycle times come from MES or ERP, not from the controller or the gateway.

Verify before you rely on this: Whether your Rockwell controller family and firmware include a native OPC UA server, and what it costs or requires, has changed in recent years and must be confirmed with Rockwell for your exact platform and firmware level rather than assumed from any historical description, including this page. On the gateway side, confirm licence tiers and how tags or devices are counted, the supported controller families and firmware, and the platform requirements with the gateway vendor before purchase. Do not treat any tag-count figure or product capability described here as a purchasing input.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Machine Data → OEE Mapping Kit
Which nodes to subscribe to, how they become Availability, Performance and Quality, and which companion specification already gives you the answer, so you stop inventing tags.
Get the free mapping kit →
Free, no course, no login