Connecting AI to a 1990s PLC Without Ripping the Floor Apart

The most common objection to industrial AI adoption at Tier-1 plants is not skepticism about the technology. It is infrastructure reality: "We have PLC racks installed in 1994. We are not replacing them for software." This is a reasonable position, not a conservative one. A ControlLogix replacement project on a 48-station line can cost $800,000–$1.4 million in hardware, re-programming, and validation labor. No plant manager approves that project because a software vendor says their AI needs a modern PLC environment.

The architectural premise of Intuigence is that it should not require it. The read-only OPC-UA and MQTT bridge approach allows live PLC telemetry to flow to an analysis layer without modifying existing ladder logic, without touching existing network segments, and without requiring the PLC itself to run anything new. This is not a workaround — it is the correct architecture for an IT/OT integration that respects operational technology constraints.

What "Read-Only" Actually Means

A read-only OPC-UA connection to a PLC is exactly what it sounds like: the OPC-UA client requests tag values from the server; the server returns them; nothing is written back. The PLC program does not change. The scan cycle does not change. The ladder logic does not change. The connection is transparent to the PLC's normal operation — it is the equivalent of plugging a meter into a test point without altering the circuit.

OPC-UA (IEC 62541) was designed with this security model in mind. The server exposes a namespace of available tags; clients can subscribe to any tag they have permission to read. In most industrial deployments, the OPC-UA server is configured to expose a read-only endpoint for external clients, keeping all write access internal to the supervisory control network. This is the standard configuration on Rockwell ControlLogix (via the FactoryTalk Linx OPC-UA server), Siemens S7-1500 (via the integrated OPC-UA server in TIA Portal), and Beckhoff TwinCAT (via TF6100 OPC-UA Server).

The telemetry that flows through this read-only connection — tag values, timestamps, quality indicators — is the same data the PLC is already generating. Nothing new is computed in the PLC. The AI analysis layer consumes the data and applies correlation and pattern-matching algorithms on its own infrastructure, completely separated from the OT network.

The OT/IT Network Boundary

The most sensitive integration question is not the PLC protocol — it is the network architecture. Most Tier-1 plants maintain a strict separation between the OT network (PLC control networks, typically Ethernet/IP or PROFINET) and the IT network (corporate LAN, MES servers, internet access). This separation is a security requirement, not a preference. The OT network controls physical equipment; unauthorized access to it represents a safety and production risk that justifies substantial architectural conservatism.

The standard approach for bridging OT to IT without compromising the OT segment is a one-way data diode or a secure OPC-UA gateway device deployed in a demilitarized zone (DMZ) between the two networks. The gateway device has a read-only connection into the OT network via OPC-UA and a publish connection out to the IT network or a cloud endpoint. Data flows one way: OT to IT. No path exists for data to flow from IT into the OT network through this bridge.

MQTT Sparkplug B is an increasingly common alternative for this pattern, particularly in greenfield deployments or plants that have added MQTT infrastructure for IIoT projects. The Sparkplug B specification defines a payload format and topic namespace convention for MQTT that supports structured PLC data delivery — birth certificates (tag metadata), data messages (tag values), and death certificates (connection loss notifications). A Sparkplug-enabled MQTT broker deployed in the DMZ layer can relay PLC telemetry to cloud-side subscribers without requiring direct connectivity between the cloud and the OT network.

Legacy PLC Connectivity: The Real Constraints

The "1990s PLC" framing in this article's title is not hyperbole. Many Tier-1 stamping and machining plants in the Midwest are running Allen-Bradley PLC-5 or SLC 500 systems installed in the late 1990s and early 2000s — platforms that predate OPC-UA and do not natively expose an OPC-UA server. The same is true for older Siemens S5 and early S7-300 deployments.

For these platforms, native OPC-UA is not available, but that does not mean the data is inaccessible. There are two standard approaches:

Protocol Gateway Devices

Hardware gateway devices — examples include the Kepware KEPServerEX on the software side and dedicated hardware like the Moxa MGate series — can translate legacy PLC protocols (Allen-Bradley DF1, Modbus, DH+, DH-485) into OPC-UA or MQTT on the outbound side. The gateway communicates with the legacy PLC using the protocols the PLC understands, and translates the data into modern formats for the analysis layer. The legacy PLC does not need to be modified; the gateway handles the translation at the network layer.

The limitation of this approach is latency: the translation adds a small lag (typically 50–200ms depending on gateway hardware and poll rate) that is acceptable for fault diagnosis and process monitoring but would not support real-time control applications. For trace intelligence purposes — where we are analyzing patterns over minutes, not milliseconds — this latency is irrelevant.

Direct Register Polling

For Allen-Bradley SLC 500 and PLC-5 systems with the standard 1761-NET-ENI or 1784-KTx ethernet interface, it is possible to poll data table registers directly via Ethernet/IP using the CIP (Common Industrial Protocol) driver. Most OPC-UA server software (including KEPServerEX) includes a CIP driver that can read SLC 500 data table files (N, F, B, T, C file types) without modifying the PLC program. The tag address mapping is done in the OPC-UA server configuration, not in the PLC.

We are not claiming that every legacy PLC can be connected without engineering effort. On very old installations with non-standard wiring, non-standard DH+ topologies, or firmware versions below the minimum supported by available gateway software, the integration work can be significant. What we are saying is that the integration is a configuration and networking problem, not a PLC programming problem — and it does not require changes to ladder logic that has been running reliably for 20 years.

A Synthetic Scenario: Mixed-Generation Assembly Line

Consider a knuckle and control arm assembly line at a Tier-1 chassis supplier in western Michigan. The line was originally installed in 1998 with Allen-Bradley PLC-5 controllers on a DH+ network. Between 2008 and 2015, the plant upgraded the machining stations at the front end of the line to Rockwell ControlLogix, but the press and assembly stations at the rear of the line — Stations 22 through 38 — remain on the original PLC-5 hardware.

The front-end ControlLogix stations expose native OPC-UA via FactoryTalk Linx. The rear-end PLC-5 stations communicate via DH+ to a single PLC-5 gateway rack, which has an Ethernet adapter module that allows EtherNet/IP communication to the corporate LAN segment (already in place from a MES integration project in 2017).

The integration architecture for trace intelligence on this line:

• Front-end stations (ControlLogix): direct OPC-UA subscription via an OPC-UA client deployed on a dedicated industrial PC in the panel room DMZ. No configuration changes to the ControlLogix project.
• Rear-end stations (PLC-5): KEPServerEX running on the same panel room PC, configured with CIP driver polling the PLC-5 data table files at 1-second intervals. KEPServerEX's OPC-UA interface exposes the polled data on the same OPC-UA namespace as the ControlLogix data, with station-aligned tag naming applied in the server configuration.
• Data forwarding: an MQTT Sparkplug B publisher on the panel room PC subscribes to the full OPC-UA namespace and publishes to a Sparkplug broker in the plant's IT DMZ. From the broker, the telemetry flows to the cloud-side trace analysis infrastructure.

Total integration work for this configuration: approximately 3 days of engineering time. No PLC programming changes. No network topology changes. No downtime on the production line. The panel room PC is a new addition, but it communicates only via read-only OPC-UA and MQTT publish — no write paths into either PLC environment.

Cybersecurity Considerations

ICS security frameworks — including NIST SP 800-82 (Guide to OT Security) and the IEC 62443 series — provide specific guidance on read-only data extraction architectures. The architecture described above — read-only OPC-UA client in a panel room DMZ, MQTT publish to an IT-side broker — is consistent with the zone-and-conduit model in IEC 62443-3-2, with the panel room PC operating as a conduit between the OT zone and the IT zone, carrying data in one direction only.

What this architecture does not do: it does not put cloud infrastructure into the OT zone. The panel room PC can be provisioned with only the OPC-UA client and MQTT publisher software, with no inbound network connections from outside the OT zone. If the cloud-side infrastructure becomes unreachable, the OT zone is unaffected — the PLC continues to run its existing program, and the panel room PC continues to collect telemetry locally, queuing messages for when the connection is restored.

The IT security question — what happens to telemetry data in the cloud — is a separate topic from the OT security question. The OT security answer is: nothing changes in the OT network. That is both the architectural goal and the proof point that allows Tier-1 plants with legitimate OT security concerns to move forward with a trace intelligence deployment without treating it as a security exception.