Teardown: A Multi-Site Telemetry Pipeline for Energy Operations

The pipeline, in four rules

Multi-site operations dashboards are a pipeline problem wearing a visualization costume. The charts are a solved problem; moving telemetry off distributed sites reliably — without ever touching the control layer — is the build. Four rules shape ours.

Rule 1 — Read-only, out of OT, no exceptions. Everything flows through historians, supported export paths, and vendor APIs — paths that read from the operational environment without reaching into it. This is non-negotiable by design: the analytics layer must be architecturally incapable of affecting control systems. It's also the rule that gets you through the conversation with the controls engineer, who has met consultants before.

Rule 2 — Assume every site's link is bad. Field connectivity drops, satellites lag, cell backhaul flakes. The extraction layer buffers locally and backfills on reconnect, and the warehouse handles late-arriving data as a normal case, not an exception. A pipeline designed for clean connectivity is a pipeline designed for a different industry.

Rule 3 — Time is the hardest join. Every dashboard aggregation assumes timestamps align across sites — and they don't, natively. Different historians stamp in different zones, some in local time with daylight-saving jumps, some drift because nobody's synced a clock since commissioning. Everything normalizes to UTC at ingestion, with per-source offset tracking. Skip this and your cross-site comparisons are quietly wrong twice a year and subtly wrong always.

Rule 4 — Model sites as one fleet with local dialects. Same physical quantity, different tag names, units, and conventions per site. A mapping layer normalizes tags and units into one fleet-wide schema — so "compressor discharge pressure" is one column, not nine site-specific mysteries. That mapping table is the pipeline's real deliverable; the dashboards just read it.

Where the first version broke

A dead feed looked like a healthy site. One site's export job silently stopped; the dashboard kept showing its last received values — flat, plausible, green. Days of "stable production" that was actually a frozen number. The fix is structural: staleness is a first-class signal. Every panel carries data age, and a feed that goes quiet turns its site visibly gray instead of confidently stale. A dashboard must never look more certain than its data.

Daylight saving created a phantom production spike. Two sites in different zones, one historian stamping local time — the November fallback hour double-counted an hour of production in cross-site totals. Small number, but it surfaced in a report an operations manager checked by hand, which is the worst possible place to lose credibility. UTC-at-ingestion (Rule 3) exists because of exactly this morning.

The full teardown — the historian extraction patterns by vendor family, the buffering-and-backfill design, the tag-mapping workbook format, and the staleness display rules — lives in the Builder library.