How to read plant data without modifying the control system

A controls engineer asking what you intend to touch is not being obstructive. Three things sit behind the question, and each has a different owner. Answering them properly is control systems and automation engineering work in its own right, whether or not an analytics layer follows.

The equipment warranty, which usually excludes faults arising from unauthorised modification of the control system. The safety case, which was assessed and documented against a specific configuration, and which has to be revalidated if that configuration changes. And the cyber boundary, where a new device on the process network is a new attack surface and, in many organisations, a change that requires its own approval.

An answer that satisfies all three is specific about the path, the direction of data flow and the enforcement mechanism. An answer that says the connection is read-only, without saying what makes it read-only, satisfies none of them.

Read-only is a property of how the path is configured and enforced, not an intention. There are three places it can be made real.

At the server, through rights. An OPC UA server can be configured so the client certificate presented by the acquisition host has browse and read permissions and no write permission. This is verifiable in the server configuration and is the cleanest answer for a modern DCS, because the control system itself enforces the restriction.

At the protocol, through function codes. Modbus separates reads from writes by function code. The read functions are 1 and 2 for coils and discrete inputs and 3 and 4 for holding and input registers; the write functions include 5, 6, 15 and 16, and also 22 and 23, the last of which combines a read and a write in one transaction. Allowlisting only 3 and 4 will block reads a device legitimately needs, and denying only 6 and 16 leaves four write paths open, so a rule built on that pair does not make a client read-only. Allowlist the documented functions and register ranges the application actually requires and deny the rest, and check that the device enforcing it inspects Modbus function codes rather than only ports, because a network access list cannot see them.

At the wire, through a diode. A unidirectional gateway allows traffic in one direction as a physical property rather than a configuration. This is the strongest answer and is normal in nuclear, defence and some transmission environments. It also complicates timestamp handling and any protocol that expects an acknowledgement, so it is worth reserving for cases that genuinely need it.

Plant historian. PI, IP.21, Wonderware and similar. Already downstream of control, already collecting, and reading it usually adds no load to the process network. The path is worth confirming, because a historian that sits inside the control network or replicates from it is not as far downstream as its name suggests. Usually the lowest-risk path and the fastest to approve. The constraints are resolution and retention: many historians compress aggressively, and a signal stored at one-minute averages cannot be un-averaged later.

OPC UA. The modern standard, with per-certificate rights and built-in security. Most DCS platforms expose a server as a licensed option. Where one already exists, this is normally the preferred path. Where it does not, adding it is a change to the control system and needs the same approval as any other.

OPC DA. Legacy, COM and DCOM based, Windows only, and awkward to secure across a network boundary. Common on older installations. Workable, usually via a tunneller so DCOM does not have to cross the boundary at all.

Modbus TCP. Ubiquitous, simple, and easy to constrain by function code. No native security, so it depends entirely on network segmentation. Register maps are often undocumented or stale, which is usually the real cost rather than the protocol itself.

MQTT, including Sparkplug. Publish rather than poll, which suits constrained links and reports by exception. It requires something on the plant side to publish, so it is an addition rather than a read of what is already there.

PROFINET and fieldbus. Closest to the process and the most intrusive to join. Reserve for cases where the data genuinely does not exist further up, and expect the safety and warranty review to be correspondingly heavier.

What Yuji supplies for this. The Yunify protocol gateway speaks the paths above, OPC UA, OPC DA, Modbus TCP, MQTT with Sparkplug and PROFINET among them, and normalises them into one tag model so the acquisition decision does not have to be made per protocol. It writes into the Yunify Historian, a time-series store that sits on the site operations network and keeps the raw record at full resolution alongside the plant state that explains it. Both run on the plant side of the boundary described below, and neither requires a change to the installed PLC, DCS or SCADA. Where a site already has a historian it stays the source, and the gateway reads from it rather than replacing it.

The accurate answer is that it depends on the contract, and the contract is usually clearer than people expect once it is read.

What typically does not put a warranty at risk: reading from a historian; reading through an OPC server the OEM supplied and supports; connecting acquisition hardware on a network segment that is separated from the control network by a firewall the plant controls.

What typically does: modifying the controller programme, including adding logic purely to expose tags; changing scan time or loading in a way that affects deterministic behaviour; placing an unapproved device directly on the control network; changing configuration inside the OEM's scope of supply.

There is a straightforward way to remove this as an objection, and the wording is set out in does connecting to a DCS void the OEM warranty. Write to the OEM describing the exact path, the direction of data flow and the enforcement mechanism, and ask them to confirm in writing that it falls outside the exclusions. Doing this before a pilot costs an email. Doing it after a dispute costs considerably more.

The Purdue reference model, which most industrial cyber standards assume, separates field devices and control at the lower levels from site operations above, with a demilitarised zone between plant and enterprise. IEC 62443 works from zones and conduits rather than fixed levels: group assets by risk, and define and control every path between groups. The two often land in a similar place on a real plant, but the standard asks for a risk assessment rather than a particular diagram.

An on-premise analytics host generally belongs at the site operations level, reading upward from control and never writing back down. Keeping it on site rather than in a cloud tenancy also narrows the questions about egress, data residency and third-party access to the outbound paths that remain, such as remote support, updates and backups, which for assets with public or sovereign participation is often a procurement gate rather than a preference. What that architecture does and does not remove is set out in on-premise and air-gapped analytics for OT.

One boundary is not negotiable, and where AI can and cannot sit relative to a safety instrumented function covers it in full. IEC 61511 requires the safety instrumented system to be independent of the basic process control system, to the extent that its integrity is not compromised by anything the control system does. Analytics can consume information about safety system state where a proper read-only interface exists, and it must never write into that path or become something a safety function depends on. If a proposal blurs that line, the answer is no regardless of the technical elegance.

A short list, worth putting to any vendor proposing to connect to an operating plant.

Which exact path will you use, and does it already exist. What enforces read-only, and can that enforcement be shown in a configuration file. What hardware goes on which network segment. What happens to acquisition if the link to your host fails, and does anything queue on the plant side. What resolution and retention do you need, and does the historian already meet it. What is the rollback procedure. And who signs off the change under our management-of-change process.

Yunify Edge is built to be answered with on that list. It acquires over OPC UA, Modbus, MQTT or PROFINET from the control system already installed, runs on a single on-premise host, and does not alter control logic. That is not the same as touching nothing: exposing new tags, adding a server or joining a fieldbus is an engineering change and belongs in the site's management of change process even though the logic is unchanged. The claim worth checking, from us or from anyone else, is not that a system is read-only but what makes it so.