Your historian believes whatever it is told

Somebody disputes a number. A customer says the batch was out of spec, or a vendor says your pump was never run outside its curve, or an auditor wants to know what the flow was at four in the morning on a Tuesday in March.

You go to the historian, and there it is. Reading, tag name, site, timestamp. Argument settled.

Here is the awkward question. How does that row prove it came from that sensor?

The honest answer, on my own plant#

I run a working estate — a few sites, a control room pair, a broker, a historian with a standby. I built it, so I know exactly what is in it, which makes it a fair thing to interrogate.

I published a message onto the plant's messaging backbone. The message was addressed as coming from one site, and the data inside it claimed to be from a different one.

The historian recorded the claim inside the message. The address it actually arrived on was discarded.

I did not need a password to do it. The reading is now in the database, looking exactly like every other row, and there is nothing in that row — or in any column next to it — that could tell you it was not produced by the site it names.

To be clear about what this is and is not: this was my own equipment, on an isolated network, and the point is not that anyone can walk in. The point is that once something is on the wire, the record has no way to argue with it.

Why it happens: everything in the middle speaks for itself#

A reading does not travel from the sensor to the database. It gets handed over, repeatedly, and each box in the middle takes delivery and then sends its own message onward.

That is not a flaw somebody introduced. It is what those boxes are for. A protocol converter exists to convert. A broker exists to accept from many and deliver to many. A collector exists to collect. Every one of them takes something in, and emits something new under its own name.

The consequence is easy to miss: the sensor's identity does not survive the first handover. After that, every hop is vouching for the hop before it, and by the time a number reaches the database the only thing supporting it is a chain of boxes each saying "this is what I was given."

"But we use encrypted protocols"#

This is the sentence I would most like to retire.

It is usually true, and it is answering a different question. Encryption on a link protects that link. It stops somebody reading the conversation between two boxes, and it proves each of those two boxes is who it says it is.

It says nothing at all about whether the reading inside was produced by the instrument whose name is on it.

An encrypted link with an unverified payload is a sealed envelope with an unsigned letter inside. The courier is beyond reproach. The contents are anybody's guess.

That distinction — protecting the journey versus proving the origin — is the whole of this piece. Most plant architectures do the first thoroughly and the second not at all, and the gap is invisible because everything works perfectly until somebody disputes a number.

What else falls off on the way#

While I was looking, I compared what four different paths into the same database actually record.

The older ones kept two things the newer ones dropped. One is quality — the instrument's own statement about whether it trusted its reading. The other is the difference between when something happened and when it was written down.

Both of those disappeared as the plumbing got more modern. Nobody decided to discard them; each new path was built to move a value from A to B, and the value was the obvious thing to carry. Quality is what tells you a reading was a sensor fault rather than a process excursion. Without it, a bad number and a real number look identical for ever.

What I would check on Monday#

None of this needs a purchase, and most of it is a question rather than a project.

Pick a row in your historian and try to prove where it came from. Follow it back hop by hop. The first hop where the answer is "because that is what arrived" is where provenance ends. It is usually earlier than people expect.

Ask what happens if two things claim to be the same site. In a lot of systems the answer is that the later one simply overwrites, or both are stored, and nothing anywhere notices the disagreement.

Check whether quality made it into the database. If your historian has no column for it, every bad reading in there is indistinguishable from a good one.

Ask whether "encrypted" was ever meant to mean "verified". If a design relies on the second, someone should be able to point at where the checking happens.

None of this makes a plant insecure by itself. What it does is put a number on how much a historian row is actually worth as evidence — which is worth knowing before you use one to settle an argument.

The four paths, the schemas, the message capture and the exact line of configuration that decides which claim wins are in the lab notes. The other half of the same question — not where a reading came from but when, and why two paths into one database disagree about it — is here.