Adding Predictive Maintenance to Ignition SCADA — Without a PLC Write Path

If your plant already runs Ignition, you have something most predictive-maintenance vendors quietly wish for: a single, well-structured source of machine data that's already normalized across every PLC on the floor. The question isn't whether you can add ML-based condition monitoring — it's how to do it without re-wiring anything, re-validating the control system, or handing a new tool write access to your process.

The clean answer uses a capability Ignition already exposes: its OPC-UA server.

Where the data already lives

Ignition (by Inductive Automation) sits between your PLCs and your operators. Its device drivers connect to Allen-Bradley, Siemens, Modbus, and other controllers; its tag system normalizes those values; and its Gateway exposes them through a built-in OPC-UA server. Operators see HMI screens; the Tag Historian writes values to a SQL database.

That OPC-UA server is the integration point. A predictive-maintenance system doesn't need to talk to your PLCs directly, install new drivers, or sit inline with anything. It connects to Ignition as an OPC-UA client and subscribes to the tags you choose — vibration, temperature, pressure, current, RPM, machine state. Ignition is already reading those values for the HMI; the PdM layer just listens to the same stream.

This is one step further from the control system than connecting to a PLC directly. You're reading from a SCADA platform's published server, not reaching into a controller.

Read-only by architecture, not by configuration

OPC-UA clients can read, write, and call methods. A monitoring layer should be constrained to a strict subset, and the strongest assurance is structural: no write capability in the code at all.

Subscribe and read only. The client opens monitored-item subscriptions on the chosen tags and receives updates. It never issues a Write service call to the Ignition server.
No method calls. Nothing that could change tag values or trigger Gateway actions.
No actuator path. There is no code path that maps a model output back into a write — to Ignition or anything downstream.

"We configured it read-only" depends on nobody flipping a setting. "It cannot write" is a property of the software. When an OT-security reviewer asks what the worst case is, the honest answer should be: it reads tag values Ignition already serves to its own historian.

You can layer this further with Ignition's own controls — scope the OPC-UA client's credential to read-only on the server, and put the agent in a monitoring network segment. Defense in depth means that even a misconfiguration on one layer doesn't open a write path.

What you gain on top of the Historian

Ignition's Tag Historian is excellent at storing and querying time-series. What it doesn't do on its own is predict. That's the layer predictive maintenance adds:

Anomaly detection on multi-sensor patterns the Historian stores but doesn't interpret.
Remaining-useful-life estimates so a degrading bearing becomes a planned work order, not a 2 a.m. line stop.
Fault classification from vibration spectra and bearing frequencies.
Explainability — per-feature attribution so an engineer can see why a model flagged a machine, not just that it did.

None of this changes how Ignition runs. The HMI, alarms, and historian behave exactly as before; you've added a passive analytics layer that reads the same data.

On-premise, no cloud round-trip

For regulated and security-conscious plants, the deciding factor is often where the data goes. A PdM layer that reads from Ignition can run entirely on-premise — the inference engine, the models, and the storage all stay inside the plant network. Machine data never leaves the site, and the agent needs no internet egress to function.

That keeps the deployment inside the same trust boundary as Ignition itself, which is usually how it clears review without a multi-quarter data-governance debate.

How it maps to an OT-security review

| Concern | Read-only-via-Ignition answer | |---|---| | Does it touch the PLC? | No — it reads Ignition's OPC-UA server, not the controller. | | Can it change the process? | No write service calls exist in the agent. | | What network access? | One inbound subscription to the Ignition OPC-UA endpoint (commonly TCP 4840); no egress required. | | Blast radius if compromised? | Read access to tags already in the Historian — not control. | | Where does data live? | On-premise; nothing leaves the plant. |

This is the posture an IEC 62443 SL-1-aligned deployment is built around: account for every interaction with the control system, and make the monitoring layer's interaction provably read-only.

Questions to ask before you wire it up

Does the PdM agent connect to Ignition's OPC-UA server, or does it want direct PLC access? (Server-side is cleaner.)
Does it have any write capability in its code, even unused?
Can it run fully on-premise with no internet egress?
What credential scope does it need on the Ignition OPC-UA server?
Can the vendor produce the data-flow diagram an auditor would expect?

If you've already invested in Ignition as your single source of plant truth, the predictive layer should build on that investment — read-only, on-premise, and invisible to the control system it's there to protect.

Prevly connects to existing SCADA platforms like Ignition as a read-only OPC-UA client — passive subscriptions, zero PLC write path, no required internet egress — and runs on-premise as part of an IEC 62443 SL-1-aligned deployment. See the architecture or request a technical walkthrough.