Industrial data operations

Start with a question that should be easy. What was the average availability of our battery fleet last quarter, by site? Every number needed to answer it already exists. It is being produced right now, on site, by equipment that is running correctly. And yet the answer takes six weeks, arrives as a spreadsheet, and carries a footnote explaining why two of the sites are not comparable.

Nothing in that story is a failure of analysis. The analysis is arithmetic. What failed is everything between the equipment and the arithmetic, and it failed in five specific places worth naming individually, because each one has a different fix and teams routinely apply the wrong one.

Teams that recognize the first two usually solve them, because the symptoms are loud: a connector that will not connect, a gap you can see on a chart. The last three are quiet. Nothing errors. Numbers arrive, charts render, and the defect only becomes visible when two sites are put side by side and disagree for a reason nobody can immediately explain.

Because a tag name is an address, not a meaning, and nothing in an industrial protocol was designed to carry meaning across an organization. The name exists so a controller can find a value in its own memory. It was never a promise about what the value is.

Watch one physical quantity, active power in kilowatts, appear four ways across a single fleet built over six years by three integrators.

OPC UA node id

Something like ns=2;s=WTG_07.ActivePower. Structured, browsable, and often carrying an engineering unit, which makes it the best case of the four. The browse name is still whatever the commissioning engineer typed that week.

Modbus register

Unit 3, register 40071. A number. The protocol carries no name, no unit, no data type beyond word width, and no scaling factor. All of that lives in a vendor PDF and, if you are lucky, a commissioning spreadsheet.

MQTT topic

A path such as bess/rack-3/soc, with a payload whose shape is decided by whoever wrote the publisher. The topic tree is a naming convention held up by convention alone.

REST endpoint

A vendor portal path returning JSON on the vendor's schedule, with the vendor's field names, and a rate limit that decides your sample interval for you.

These four are not variations on a theme. They differ in what they can even express. Two of them can tell you the unit; two cannot. One can push changes to you; the others must be polled. One is a namespace you can browse; one is a bare integer with a vendor document standing between it and its meaning.

So the work is not translation between naming conventions. It is adding a layer that did not previously exist: a binding from each raw address to a named, typed variable belonging to a specific asset. Fleetera's runtime has built-in drivers for OPC UA including subscriptions, Modbus TCP and RTU, MQTT, and REST, so the reading side needs no plugins at the site. The binding side is the part that has to be modeled, and it is the part that pays off later.

Fleetera can suggest those bindings. Point it at an OPC UA server and it suggests how each raw signal maps to your variables. You review the matches and approve. Nothing binds without your yes, and you can always browse and bind by hand. The suggestion saves the typing; it does not remove the decision, because a wrong binding is worse than an unbound signal. An unbound signal is visibly missing. A wrong one produces a believable number forever.

More than most teams check. A timestamp on an industrial reading is one of at least three different facts, and they are routinely stored in the same column as though they were one.

• The instant the equipment says the measurement was taken, according to its own clock.
• The instant your collector read the value, which for a polled protocol can be most of a poll interval later.
• The instant the reading reached storage, which after an outage can be hours later.

Each of these is a legitimate thing to record. The failure is recording one and reasoning as if you had another. A controller clock drifting by forty minutes is not exotic; it is a device that never had a time source and has been quietly running since commissioning. Its readings will interleave with a neighbour's in the wrong order, and every event sequence built from them will be subtly wrong in a way no chart reveals.

Then there are timezones, which fail in a more embarrassing way. A fleet spanning three countries produces local timestamps in three offsets, two of which shift twice a year on different dates. Store those as naive local times and you get an hour that happens twice each autumn and an hour that never happens each spring. Aggregate over them and the daily totals are wrong on exactly four days a year, which is few enough that nobody catches it and often enough that it matters.

Identity travels with time. In Fleetera every reading arrives tagged with its tenant, site, asset, and variable, and the pipeline preserves order per asset. Order per asset is the honest guarantee and it is worth being precise about: readings for one piece of equipment stay in sequence relative to each other. It is not a claim that two different assets' readings are globally ordered against each other, and anyone who needs that has to get it from the timestamps rather than from the arrival order.

A flat line on a chart is ambiguous, and the ambiguity is structural rather than cosmetic. It means one of two completely different things: the value genuinely has not changed, or nothing has reported a value and you are looking at the last one anybody sent. A battery sitting at a steady state of charge overnight and a battery whose connector died at midnight draw the same line.

Which of the two you are looking at depends on how the value was acquired, and the protocols differ sharply here.

• A polled protocol produces a reading on every cycle whether the value moved or not, so an absence of readings is genuinely an absence and the gap is visible.
• A change-driven protocol only produces a reading when the value moves, so a signal that is stable and a signal that is dead are indistinguishable from the data alone.
• Some protocols carry a quality or status code alongside the value, and OPC UA is the good case here. Modbus carries nothing of the sort: a register read either succeeds or the whole read fails, and a stale value inside a working device looks exactly like a fresh one.

The operational consequence is worse than a confusing chart. Alerts built on thresholds go quiet in precisely the situation you most want them loud: if the value never updates, a threshold on that value never trips, and the failure of the measurement chain hides the failure it was supposed to catch. This is the alert that never fires, and it is far more common than the alert that fires wrongly.

Because a plant historian is scoped to a plant, on purpose, and does that job extremely well. It was bought to serve the control room it sits in. It is fast, it is trusted, it holds years of history, and its tag namespace is local to that site because there was never a reason for it to be anything else.

Ask it a fleet question and three separate problems surface at once.

• There is no join key. Site A calls it WTG_07.ActivePower and site B calls it Turbine7_P_kW, and nothing in either system knows those are the same measurement. The mapping exists only in a spreadsheet, if it exists at all.
• There is no shared unit discipline. One site stores kilowatts, another megawatts, and a third a scaled integer needing a multiplier from a vendor document. Summing them produces a number, and the number is wrong.
• There is no cross-site query surface. Answering means an export per site and a merge, and the merge is a one-off script that becomes the de facto definition of the metric until somebody rewrites it differently next quarter.

None of that is a criticism of historians. It is a scope mismatch. The historian answers questions about this plant, at high resolution, for the people in this plant, and it is usually the right tool for exactly that. The fleet question needs something it was never asked to provide: a model that is the same at every site, and a query that spans all of them at once.

That distinction deserves its own page, because the three candidate answers on the market, a historian, a data lake and a data fabric, are genuinely good at different things and are routinely sold as substitutes for one another.

The short answer is that none of them is replaced, and anyone selling data operations as a replacement for your control layer is selling a rip and replace project with a friendlier name. Each of these systems owns a layer, and each was built for a boundary that has not moved. Data operations is the practice that runs across them, and it is additive by construction.

It helps to be specific about which layer each one owns, because the four are routinely discussed as if they were alternatives to each other.

So what does data operations add, if it displaces none of them? One layer that none of the four contains: a binding from each raw address or topic to a named, typed variable on a modeled asset, plus a history of those variables that spans every site and can be queried in one operation. A historian holds values against local tags. A unified namespace moves current state around. Neither records that site A and site B are measuring the same thing, because at the moment each was named there was no fleet to be consistent with.

In practice the relationship is that of a reader. Where a site has a unified namespace publishing over MQTT, the same runtime that reads equipment directly over OPC UA, Modbus and REST reads it too. Where a site has a historian, it keeps serving the control room while the fleet question is answered somewhere that knows what the tags mean. Data operations reads from these systems and models what it reads. It does not write back into them, and the equipment keeps doing its job without being asked to change, because a control system is not a place to experiment.

Five jobs, in order, each removing a specific failure from the list above. The order matters because each job depends on the one before it: you cannot model a signal you cannot read, and you cannot query a fleet you have not modeled.

Acquire, at the site

Read from equipment over its native protocol, without asking the equipment to change. The collector runs at the site because the equipment network usually does not route anywhere else, and because a reader on the far side of a wide-area link is a reader that stops during every outage.

Buffer, locally

Keep recording while the uplink is down. A dual hot and cold buffer keeps recording at the site through restarts and through a lost connection, and streams what it holds once the link returns. A gateway that cannot reach the cloud is still collecting.

Stamp identity

Attach tenant, site, asset and variable to every reading on the way in, so nothing downstream has to infer what a number is from where it arrived.

Model

Bind raw addresses to typed variables on real assets, and define the asset type once so every instance inherits the same variables, units and structure.

Store for querying

Keep recent data at full resolution for live work, roll older data into hourly and daily aggregates, and serve any asset, variable and time range through one query that spans the whole history.

The fourth job is the one that changes the economics, and the one most often skipped because its payoff is deferred. Define an asset type once, with its variables, units, and structure, then stamp it across the fleet. Every instance stays consistent, and fleet-wide queries stay possible. Skip it and every site is an integration. Do it and a new site is a configuration.

Storage deserves one clarification, because it is a common source of surprise. Retention is a query window, not a delete: queries beyond the window narrow gracefully to the resolution you have, rather than erroring. Rolling into hourly and daily aggregates is a real loss of resolution, by design. It is the trade that keeps a decade of history affordable, and it is worth understanding before planning an analysis that assumes full resolution five years back.

This is the failure that survives every other fix, and the one that does the most damage, because its output is a number looking exactly like the number you wanted.

Take availability. At plant A it is computed from the turbine controller's own state code: the fraction of the period the controller reported an operational state. At plant B, commissioned by a different integrator three years later, the same nominal metric is computed from a different state enumeration, where one of the codes plant A counts as running is a warning state plant B excludes. Both numbers are defensible. Both are labeled availability. They differ by two points, permanently, for a reason living in nobody's documentation.

Now add the denominator. Does the period exclude planned maintenance? Grid curtailment? A site that is offline because you asked it to be? Every one of those is a reasonable choice, and every combination produces a different number from the same underlying data. Two plants can agree on every reading and still disagree on availability by a margin larger than the effect anyone is trying to measure.

• Different source signals behind the same metric name.
• Different treatment of states that are neither clearly up nor clearly down.
• Different denominators, which is usually where the largest divergence hides.
• Different aggregation order, because averaging daily averages is not the same as averaging over the period.

There is no clever query that fixes this after the fact. The fix is structural and upstream: the definition has to live in one place, attached to the asset type rather than to a site, so every instance computes the same thing from the same variables. When a definition changes it changes everywhere, at once, visibly, instead of drifting apart one site at a time.

Provenance is the second half. When two numbers disagree you need to see which inputs produced each one, over which window, from which asset. A metric you cannot trace is a metric you cannot defend in the meeting where it matters, and the meeting where it matters is always the one where somebody is being asked to spend money.

The link between a site and the cloud is the least reliable component in the whole chain, and the one you control least. Rural sites, satellite backhaul, a substation upgrade, a contractor with a trencher. Any design assuming continuous connectivity is a design that will have holes in its history.

So the collector holds readings at the site. Fleetera's runtime keeps a dual hot and cold buffer that records through restarts and through a lost connection, and streams what it holds once the link returns. That is the mechanism, and it covers the ordinary case well.

It is worth being straight about the boundary, because the boundary is where the surprises are. The buffer has a configured size on disk and a configured maximum age. An outage that outlasts either does cost you data: the oldest readings are discarded to make room for new ones. The runtime counts what it discarded rather than hiding it, so the loss is a number you can look at rather than a gap you find months later. Sizing that buffer against the longest outage you actually expect is a real decision, and it is a decision, not a default.

Not by whether data is arriving. Data arrives in every failed version of this too. The useful tests are all about whether the next question costs anything.

These are deliberately unglamorous. None is about volume, latency or dashboards, because all three can look excellent on top of data that cannot answer a fleet question. The point of operationalizing fleet data is that questions get cheap, and cheap questions are the thing you can actually measure.