You need a second system reading the same PLC data that SCADA already polls. What could that do to the line?

What the controller is doing while you poll it

A programmable logic controller runs a cyclic scan. It samples its inputs, executes the program, writes its outputs, and begins again, and the machine's behaviour depends on that loop finishing inside a predictable time. Communications are serviced around or inside the same cycle, which means answering a request for data is work the controller performs with the processor that is also running the logic. Depending on the platform there may be a separate communications module that absorbs some of it, and there may not be.

That single fact reframes the request. You are not attaching a read replica to a database with spare capacity. You are asking a device with a hard timing job and a fixed, usually modest, budget to do additional work on somebody else's behalf. The right first question is therefore not which protocol to use, it is what headroom exists: how much of the scan time is already consumed, how many concurrent sessions the device supports, and what the controls engineer has observed when the existing SCADA poller is at its busiest.

The failure mode when you get this wrong does not appear in your system. It appears as scan-time growth in the controller, which presents as a machine behaving slightly differently, and nobody in the plant will attribute that to the analytics project that went live a fortnight ago.

Why a second master is not free

Modbus TCP will accept more than one connection, and the device will accept more than one client, right up to the point where it will not. Controllers and gateways carry a bounded number of concurrent sessions, and the behaviour when you exhaust them is rarely graceful: a new connection may be refused, or an idle existing one may be dropped to make room, and the session that gets dropped could be the one the control room is watching. A polling client that reconnects aggressively after every timeout can turn a transient into a sustained denial of the device's own communications capacity.

Poll rate is the other half of it. Requesting a value ten times a second from a controller whose scan is slower than that does not give you a faster signal, it gives you the same value repeated at ten times the cost. Worse, sampling on your own timer against a loop running on its own timer produces aliasing, so a value that oscillates within the scan can be caught consistently at one point in its swing and look like a stable reading that is simply wrong. Where the protocol supports it, subscribing to change with a defined publishing interval and a deadband is both cheaper for the device and more honest about what changed, because the device decides when there is something to say. OPC UA offers that model, along with an address space in which a node can carry a data type and a description rather than being a bare number.

flowchart LR
  P[PLC scan loop] --> S[SCADA poller]
  P --> G[Gateway or historian]
  G --> B[Message broker]
  B --> A[Analytics consumer]
  B --> C[Cloud platform]
  A -. direct poll .-> P

The line worth arguing about is the dotted one. Every consumer that reaches the controller directly is another session and another share of the scan, whereas consumers hanging off the broker cost the controller nothing at all.

A register is a number whose meaning is stored elsewhere

Register-level protocols carry no semantics. A Modbus holding register is sixteen bits with no name, no unit, no scaling factor and no quality flag. The convention that a particular register holds a bearing temperature in tenths of a degree lives in a vendor document, a spreadsheet, or the memory of whoever commissioned the machine. Floating-point values are assembled from consecutive registers, and the word order in which they are assembled is a vendor decision, so the same bytes read under the wrong convention produce a plausible-looking number that is nonsense.

This is why the second consumer is dangerous even after the load question is answered. A successful read is not a correct read. Nothing in the protocol tells you that the register you are reading is the one you think it is, that the scaling you applied is the scaling the machine intended, or that the controller has stopped writing to that address because a program change moved the value somewhere else. The value keeps arriving, it stays inside a plausible range, and it is fiction.

The mitigation is to treat the tag map as a versioned artefact with a named owner, and to validate against physics rather than against schema. A temperature that has not moved all shift, a flow reading that does not fall when the machine stops, a pressure sitting exactly at zero or exactly at full scale: those are the checks that catch a mis-mapped or abandoned register, and they belong in the pipeline rather than in somebody's judgement of a chart.

Read from the aggregation point, not from the device

The answer that ends the discussion well is that you usually should not add a second reader at all. Most plants already run something that reads the controller once and republishes: a SCADA system with a data server, a process historian, or an edge gateway. Taking your feed from there leaves the controller with exactly one client, gives you somewhere to add tags without touching the control network, and gives the OT team one interface to audit rather than a growing set of connections nobody authorised.

Where a gateway is the right answer, publishing onward over MQTT with a topic structure and payload convention agreed in advance is what stops the next three consumers becoming the next three pollers. A convention such as Sparkplug exists precisely because raw MQTT gives you transport and no agreement about naming, about announcing that a device has come online or gone offline, or about what a client should assume when it connects and receives a retained value of unknown age. That last point deserves stating: a retained message means a new subscriber immediately gets a value, which is convenient and is also exactly how a stale reading is mistaken for a live one.

The schedule belongs to the controls engineer

What separates an experienced answer is knowing whose calendar governs the work. A change to a controller's program, and in many plants any new connection to the control network, is a change to a system that is validated, sometimes safety-relevant, and running. It happens inside a planned shutdown window, it is tested by a controls engineer, and that window may be weeks or months away. A plan that assumes tags can be added on a sprint boundary is a plan that quietly gets abandoned.

So the design that survives decouples your delivery from their window. Take everything you can from the aggregation layer. Batch the requests that genuinely need controller changes into the next planned outage, and write the tag map down as a contract, so that when a block is renumbered the change arrives as a version bump rather than as a dashboard that has been silently wrong since the shutdown.

Adding a consumer to a controller is a change to a real-time system with a fixed budget, and the values it returns have no units attached. Both of those belong to somebody else until you make them yours.