Getting historian data out without opening the plant

Every analytics ambition in upstream and midstream eventually arrives at the same door: the data you want lives on the control network, and the control network exists to keep people and equipment safe. Getting through that door badly is how operational technology incidents happen. Getting through it well is mostly architecture, agreed in advance, with the right people in the room.

This is written for the situation we meet most often: an operator with years of high-frequency history in a process historian, a genuine analytics use case, and an operations or process-safety function that is — entirely reasonably — unwilling to let a data team open a path into the plant.

Start by conceding the point

The safety objection is correct. A control system was designed for determinism and availability, often over a decade ago, on the assumption that it would not be reachable from a general-purpose network. Patching windows are rare because the plant does not stop. Many devices cannot be patched at all. The blast radius of a compromise is not data loss, it is equipment and people.

So the design goal is not "secure connectivity to the plant." It is getting a copy of the data out without creating a path in. Those are different problems, and the second one is achievable without argument.

The architecture that gets signed

The pattern that survives review, in the order the data moves:

Level 0–2: the process network, untouched

Instruments, controllers and the control-system historian. Nothing we build reaches into this zone, and nothing in this zone initiates a connection outward on our behalf. If a proposal requires a change here, it is the wrong proposal.

Level 3: the operations DMZ

A replica historian or an aggregation node sits here, fed by the vendor's own replication from the control-system historian. This is the boundary most operators already have, and it is the layer where a project should be asking for capacity rather than for new pathways.

The diode, or the equivalent you can defend

Between the operations DMZ and the enterprise network, the data crosses in one direction. A hardware data diode makes this physically enforced; a properly configured unidirectional gateway or a broker with strictly outbound-initiated, authenticated, allow-listed publication achieves it logically. Which is appropriate depends on your risk assessment and your regulator, not on our preference — but the principle does not vary. Data leaves. Nothing enters.

Enterprise: where the work happens

Landing zone, time-series storage, contextualisation against the asset model, and everything downstream — analytics, models, dashboards. All of it operates on a copy. If this entire environment were compromised tomorrow, the plant would be unaffected. That property is what makes the architecture signable.

Context is the actual deliverable

A tag history is not information. FIC_10432.PV at one-second resolution for nine years is a large amount of storage and no insight whatsoever until it is attached to an asset, a unit, a well, a service, and a set of engineering limits.

This is where these projects consume their time, and where they are chronically under-estimated. The asset model — which tag belongs to which equipment, which equipment belongs to which facility, what changed when — usually lives partly in the historian, partly in the maintenance system, partly in a P&ID, and partly in the memory of one engineer approaching retirement.

Treat it as a workstream with a named owner and a schedule. Do not treat it as a task inside the first sprint.

Resolution, retention and the decision you cannot reverse

Historians compress. Compression settings were chosen years ago for trending and alarm review, not for machine learning, and they are frequently aggressive enough to remove the signal a model would need — particularly for fast-moving equipment behaviour.

Two practical consequences. First, check the actual compression and retention policy before scoping any use case that depends on high-frequency behaviour; the data you assume you have may already be gone. Second, if you intend to do this kind of work in future, change the policy for the relevant tags now, because history you did not keep cannot be recovered later. A tag retention review is a cheap decision this quarter and an impossible one in two years.

The most valuable thing an energy analytics assessment produces is often a retention policy change — a decision that costs almost nothing today and is irreversible if deferred.

Who needs to be in the room

The failure mode we see is a data or digital team designing this in isolation and presenting it to operations for approval. It does not get approved, and the relationship starts adversarial.

The people who need to be present from the first workshop: the control systems or automation engineer who owns the historian, whoever owns OT security, a process or operations engineer who can say whether the use case matches how the plant is actually run, and the enterprise architect who will own what is built. Four people, half a day, before anything is designed. It is the highest return meeting in the programme.

What good looks like six months in

• A one-way data path signed by OT security, reusing existing replication where possible.
• An asset model that resolves tags to equipment, maintained rather than assembled once.
• A retention policy that reflects analytical intent, not just trending.
• Engineers reviewing exceptions rather than assembling spreadsheets — the same-day answer instead of the following-week answer.
• No new inbound path into the control network. Not one.

That last point is the one worth holding. Every other item on the list can be improved later. A path into the plant, once opened, tends to stay open.