30 Jul 2026 · 6 min read
Every tag needs one owner
scada · architecture · opc-ua · mqtt · uns · automation
Somebody calls you during an incident and reads a value off a screen. You are looking at what should be the same tag, on a different system, and it says something else. Not wildly different: 6.2 against 6.4, or a pump the other screen says stopped ninety seconds ago.
Which one do you believe?
There is no good answer available in the moment, and that is the actual problem. The discrepancy is a symptom. What you have just found is that more than one system claims to be the truth about that pump, and nothing in the architecture decides between them.
The rule
For any tag producer in the plant, whether that is a PLC, a flow computer, a power meter or a protocol gateway, exactly one system should consume it. That system owns what those values mean, and everything else in the business reads from that system rather than from the device.
ONE PRODUCER · HOW MANY SYSTEMS READ IT DIRECTLY
This is not a preference about products. It is the difference between an estate where a number has a provenance and one where it has several.
How a plant ends up with three owners
Nobody sets out to build this shape. It assembles itself in ordinary steps, usually years apart and usually by different people.
NOBODY DECIDES THIS · IT ARRIVES IN THREE STEPS
The SCADA that came with the plant
Not a decision anybody made. It is the control system, and it was here before the question existed.
A second system that needs the same values
Reporting, energy, maintenance, a compliance return. The quickest route to the data is another driver aimed at the same controllers.
A side channel somebody builds in a hurry
The sanctioned path means a licence conversation and a change window. A script and a broker take an afternoon.
One producer, three consumers, and no meeting at which anybody agreed to that. It is the sum of three reasonable answers to three unrelated questions.
The last step is the one I have taken myself, which is why I would rather argue this from experience than from a standard. Some years ago I put together a monitoring stack of my own: a script reading controllers directly, into MQTT, into Grafana and a time-series database that belonged to nobody but me. It answered a question I needed answered that week, and it worked. It was also a new owner of tags that already had one, and I genuinely did not think of it in those terms at the time, because nothing in the tooling or in the review asked me to.
Every one of those steps is defensible on the day it is taken. That is exactly why the shape is so common, and why nobody in the story is careless.
The first cost: tags stop meaning one thing
ONE SENSOR · PLANT B, PUMP 3, DISCHARGE PRESSURE
THE SCADA
name
P3_DISCH_P
units
bar
update
2 s
deadband
0.05
REPORTING FEED
name
PlantB_P3_DischPress
units
bar
update
5 s
deadband
0.2
SIDE CHANNEL
name
plantb/p3/disch_p
units
psi downstream
update
1 s
deadband
none
Every report that spans the estate needs a translation table in the middle of it. That table is maintained by one person, and it is not in change control, because a translation is not a change.
Nothing forces three independently maintained tag databases to agree, so over a few years they don't. Names diverge because each was written by whoever was commissioning at the time. Scaling diverges quietly, which is worse, because a wrong name is obvious and a wrong engineering unit looks like a process excursion. Update rates diverge because each owner tuned for its own screens, and a five-second poll set against a one-second poll is enough on its own to produce the phone call this piece opened with.
The failure is not that the names differ. It is that there is no mechanism for three tag databases to disagree out loud. That is the same missing property behind drift across sites, which I have argued elsewhere is a structural consequence of where a definition lives rather than anything about discipline.
The second cost: a budget nobody watches
Controllers do not have unlimited capacity to be talked to, and the limit is a published number rather than a matter of opinion. A ControlLogix 1756-EN2T bridge supports 128 CIP connections and 128 TCP connections, in a module that tops out at 256 TCP/IP transport connections in total. An S7-1500 works from a shared pool of connection resources that runs from 96 on a 1511 to 256 on a 1516, with PG, HMI and web communication already reserved out of it before anything northbound gets a look in.
WHAT A CONTROLLER WILL ACTUALLY GIVE YOU
PUBLISHED CEILINGS
WHAT EACH EXTRA OWNER ADDS
×3
subscription sets, at three different rates
Two clients asking one aggregation server for the same item at the same rate cost one device read. Two aggregation servers asking the controller cost two, every time. The deduplication only works inside a single owner.
Three owners do not just triple the packets. Each maintains its own subscription set at its own rate, so the controller services three independently tuned request streams, and the deduplication an aggregation server performs so well internally never crosses between them.
The vendors know this well enough to have designed around it. Ignition's cold standby mode "connects to all OPC servers but does not subscribe to Tag values", documented plainly as preventing additional load on devices and networks while on standby. The redundancy feature in the product is built on the assumption that the standby must not become a second poller.
The third cost: nobody owns the answer
THREE OWNERS · THREE SETS OF CREDENTIALS ON ONE CONTROLLER
THE SCADA
service account A
can write: setpoints
audit trail A
REPORTING FEED
service account B
can write: setpoints, in principle
audit trail B
SIDE CHANNEL
my credentials
can write: read-only, in theory
no audit trail
? Who wrote that setpoint at 02:14?
? Which system does the control room treat as authoritative?
? Which one gets patched first, and who is told?
? Which one do you disconnect when the controller is struggling?
This is the one that turns an architecture argument into an operational one. With three consumers there are three sets of credentials on the controller, three audit trails, three potential write paths and no single place that can answer who changed a setpoint at 02:14. During an incident the question is not academic, and joining three logs by timestamp while a plant is misbehaving is not a task anyone should be given.
Sovereignty is the plain word for it. A plant that cannot say which system is authoritative for a value has quietly delegated that decision to whoever happens to be standing in front of a screen.
The local HMI is not a second owner
This is the exception people reach for, and it is a genuine one, so it is worth being precise about why it does not weaken the rule.
THE ONE QUESTION · DOES ANYTHING DOWNSTREAM QUOTE ITS NUMBERS?
NO · NOT AN OWNER
have as many as you like
- +Panel HMI wired to its own PLC
- +A local trend screen at the machine
- +An engineering laptop in a Designer session
- +A handheld reading a meter on the walk-round
YES · AN OWNER
one per producer, no exceptions
- !Anything writing values into a historian
- !Anything a report or invoice is built from
- !Anything a second system subscribes to
- !Anything an alarm or a KPI is calculated from
A panel HMI wired to its own PLC renders for a person standing at the machine. It publishes nothing, nothing downstream quotes it, and it must keep working when the network does not. That is the entire point of having it. It belongs to the control system rather than to the data architecture.
The test is one question: does anything downstream quote its numbers? If a system's values get stored, trended, billed against or put in a report, that system is claiming to be a source of truth, and there can be only one of those per producer.
Redundancy without a second truth
The strongest objection to all of this is that you genuinely need a DR site, and that is correct. The mistake is satisfying that need by standing up a second independent owner instead of making the single owner survivable.
YOU STILL NEED A DR SITE · TWO WAYS TO GET ONE
The distinction worth holding onto: two copies of one truth is redundancy, and two independently derived truths is a coin flip you will be asked to perform during an incident.
Sparkplug B is unusually blunt about this, having written it into the specification as a hard requirement rather than a recommendation. There MUST NOT be more than one Sparkplug Primary Host Client connected to any MQTT server, and every edge client MUST have a unique Group ID and Edge Node ID combination. The protocol refuses to let two applications be the authority for the same data, which is the same argument this piece is making, expressed as a normative statement. It is also the practical half of what a unified namespace is for: publish once, subscribe many, rather than poll the same device from four directions.
The test to run on Monday
Pick one number that matters. A pump discharge pressure, a custody flow total, a generator run status.
Then count, for that single point, how many systems open their own connection to the controller to get it. Not how many screens show it, and not how many reports contain it. How many independently ask the device.
If the answer is more than one, ask the follow-up question, which is the one this whole argument rests on: when they disagree, what decides?
Most estates find that the honest answer is whoever is standing in front of the screen at the time. That is not an architecture. It is a habit that has not been tested yet.
Running more than one system against the same controllers, deliberately or otherwise? I would like to hear how it is holding up. Reply by email.
Keep reading
Newsletter
New essays, by email.
SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.