Two Consumers, Two SLAs: The Historian Split Between the Line and the Enterprise

Two Audiences Pulling in Opposite Directions

A historian has two very different customers, and they are almost never in the same room. On the plant floor, an operator troubleshooting a stall wants the last twenty minutes of a handful of tags on screen in the time it takes to glance up - and they want it whether or not the corporate WAN is having a good day. In a headquarters analytics team, someone building a year-over-year efficiency model wants every tag from every site, stitched into one queryable timeline, and they will happily wait a few seconds for a query that spans months.

Fast-and-local versus complete-and-consolidated are not two settings on one dial. They are two service-level agreements with different priorities: the operator trades breadth and depth for immediacy and independence; the analyst trades immediacy for reach and retention. Try to satisfy both from a single historian and one of them loses. A central-only system makes the operator hostage to a network link for data generated ten feet away. A pile of standalone floor historians gives every operator what they need and gives the enterprise a reconciliation nightmare instead of an answer.

The way out is to stop treating it as one problem. Give each consumer a tier tuned to its own SLA, and connect the two so nobody has to choose.

Serving the Operator: Latency Over Longevity

The floor tier optimizes for the operator's clock. A runtime on the plant network pulls data straight from the equipment in its native protocol, applies the namespace and quality context as it arrives, and lands it in a local historian sized for the recent past - hours and days, not years. Because that store lives on the same network as the SCADA screens querying it, a lookup for "what did this tag do since the shift started" never leaves the building and never waits on a link to headquarters.

That same runtime does a second thing in parallel: it hands the structured stream to a message broker on the plant network - MQTT or Kafka - so the data is available to travel without the local historian ever being in the critical path for anything downstream. The floor tier is not a shrunken enterprise archive. It is a deliberately narrow, deliberately fast store built for the questions people ask while standing at the machine.

Why a Forwarder Sits in the DMZ

Here the plant's security architecture does something useful for us. Control-network equipment - and anything reading directly from it - is walled off from the wider network by a DMZ, and for good reason: OT gear should not be initiating connections out to corporate or cloud endpoints. That constraint is exactly why the enterprise copy is fed by a relay rather than a direct pull.

A separate runtime is placed inside the DMZ, straddling the boundary the way the boundary is meant to be crossed. It listens to the plant-side broker and relays what arrives toward the central store, so the flow moves outward from the trusted zone without anything on the corporate side ever reaching back into the control network. Where the enterprise historian is itself deployed within the DMZ, that relay collapses away - the plant egress simply targets it - but the security posture is the same either way: the data path honors the segmentation because it was drawn along it, not in spite of it.

Serving the Analyst: One Record, Many Sites

Past the boundary, the relayed streams from every plant converge into a single historian - on-premises or cloud-hosted - that becomes the analyst's one source of truth. The thing that makes this consolidation actually usable is that the hard part already happened upstream: each site's data was given its namespace path, quality flags, and source-accurate timestamps back at acquisition. So a tag arriving from the plant in one region and a tag arriving from another slot into the same schema without anyone writing per-site glue.

That is the difference between a warehouse and a landfill. A cross-site query - rank these lines by uptime, compare this quarter to last across the fleet - is a filter over uniform data, not an archaeology project that starts by figuring out what each site's exporter happened to call things.

Keeping Both Copies Worth Keeping

Running two tiers only pencils out if neither one is drowning in data that says nothing. Two habits keep both lean and honest. First, the edge only emits a reading when the value has actually moved past a configured threshold - report-by-exception - so a sensor parked at steady state stops flooding the floor store and the link to headquarters with identical numbers. Second, longer trends are held in a reduced form that keeps each curve's true shape to a tolerance you set, so a plant can retain far more history on the same disk than storing every raw sample would ever allow, without throwing away the features an engineer would actually look for.

There is a correctness dividend here too. Because tags report on change rather than on a fixed cadence, naive averaging would over-count whichever samples happened to arrive. The tiers account for the time each value was in effect, so an average or a summary computed on the floor and the same summary recomputed a year later against the central archive tell the same story - the one the process actually lived.

The Payoff

The line and the enterprise were never really asking for the same historian. They were asking for the same data, at two speeds, for two purposes - and that is precisely what two tiers on one platform deliver.