Industrial data fabric

The problem is not storage. Almost nobody in industry is short of stored data. The problem is that the stored data has no shared meaning, so every question that crosses a site boundary has to reconstruct the meaning by hand before it can be answered.

Concretely: your sites were commissioned in different years by different integrators. Each has its own tag namespace, its own units, its own idea of what a turbine state code means. Nothing anywhere records that site A's WTG_07.ActivePower and site B's Turbine7_P_kW are the same measurement, because at the moment each was named, there was no fleet to be consistent with.

A data fabric is the response to that specific gap. It adds a layer whose entire job is meaning: which asset a signal belongs to, what the signal is, in what unit, at what resolution, and who owns it. Everything else the term is used to describe, storage tiers, pipelines, catalogs, governance, follows from that layer existing.

Because it arrived in industry from somewhere else. The phrase came out of general enterprise IT, where the problem being solved was that a large organization had data in dozens of business systems and wanted to query across them without copying everything into one warehouse. In that world a fabric is mostly about federation, virtualization and governance across databases that already have schemas.

Industrial data has a different shape, so the same word ends up describing a different job. The sources are not databases with schemas, they are controllers with addresses. There is no schema to federate. The hard part is not joining two well-described tables; it is that the thing you want to join has no description at all until somebody creates one.

• An enterprise fabric mostly connects systems that already know what their fields mean. An industrial fabric has to create the meaning first.
• An enterprise fabric assumes reliable networks between its sources. An industrial one has to assume the site link will drop and keep collecting anyway.
• An enterprise fabric deals in records and events. An industrial one deals in time series with sample intervals, units, and quality that vary by protocol.

This matters practically when you are comparing products. A fabric built for enterprise data will have excellent governance and connectors to business systems, and may have nothing that runs at a site or speaks to a controller. A fabric built for industrial data will do the acquisition and the asset model, and may be thinner on the enterprise-integration side. Neither is wrong. They are answering different halves of a word.

A historian is a time-series database built for one plant, and it is very good at that. It records tags at high resolution, it survives, it is trusted by the control room, and it has years of history that predate whatever you are planning. Operations staff know how to use it. None of that is a weakness.

The differences that matter are about scope, not quality.

Two of those rows deserve a sentence more. The structure under the model is what makes an aggregation meaningful: sites contain assets and assets contain sub-assets, so a total over a site is a total over something real rather than a sum over whatever happened to be tagged. And the horizon matters because a fleet question is usually about last year rather than last hour, which is the window a historian is least tuned for.

The right conclusion is usually not that the historian should go. It is that the historian keeps doing the job it is good at, in the control room, while the fleet-level question is answered somewhere that knows what the tags mean.

A data lake is storage that accepts data in whatever shape it arrives and defers the schema until somebody reads it. That deferral is the entire design, and it is genuinely valuable: you can land data you do not yet understand, keep it cheaply, and decide later what it meant.

The cost of the deferral is that the meaning has to be supplied at read time, by whoever is reading, every time. In practice that means the meaning lives in query code. Two analysts write two versions of the same interpretation, both defensible, and the difference between their answers is invisible because it is buried in a transformation step nobody diffs.

• A lake answers where the data is. A fabric answers what the data is.
• A lake is schema-on-read, so correctness depends on the reader. A fabric records the semantics once, so every reader inherits the same interpretation.
• A lake will happily hold three incompatible versions of the same measurement. That is a feature when you are exploring and a liability when you are reporting.
• A fabric without storage underneath is a catalog. A lake without semantics on top is a file system with good economics.

They are also not mutually exclusive, and treating them as rivals is the most common category error in this whole area. A fabric needs somewhere to put the data. A lake, or a tiered store of the same character, is a perfectly good answer to that. The fabric is the layer above it, not a replacement for it.

These five are compared constantly, usually as though they were five products competing for one budget line. They are not. Each was invented to answer a different question, and two of them are not storage at all. The fastest way through the vocabulary is to read each one as the question it was built for, and then ask which of those questions you currently cannot answer.

Read as questions, they stop competing. A unified namespace is a topology: it decides how many wires there are between systems, and it is genuinely transformative at a site that had a wire per pair. A mesh is an ownership model, and it can be run on top of any of the storage answers or none. A lake and a warehouse are both storage with opposite bets on when the schema is decided. A fabric is the meaning layer, and it needs storage underneath it and benefits from a namespace beside it.

The industrial cases sharpen one of these in particular. A unified namespace solves the topology problem and is often sold as if it also solved the semantic one, which it does not: a topic tree is a naming convention, and a convention is exactly the thing that stops holding at the second site, commissioned by a different integrator three years later. The namespace tells you where to subscribe. It does not record that two topics measure the same physical quantity in different units.

This is the part that gets described in abstractions, which is a shame, because the contents are concrete and short. A semantic layer for industrial equipment holds roughly five things, and you can check any product against the list.

1. 1Asset types. A definition of what a wind turbine, a battery rack or an air handler is, made once and reused, rather than described again at every site.
2. 2Typed variables. Each measurement on that type, with a name, a data type and a unit. The unit is not decoration; it is what makes summing two sites legitimate.
3. 3Structure. Which assets contain which sub-assets, so an aggregation over a site means something rather than being a sum over whatever happened to be tagged.
4. 4Bindings. The mapping from a raw protocol address at a particular site to the variable it feeds. This is the layer that did not exist before and is the whole reason the rest works.
5. 5Provenance. Which reading produced which number, so a disputed figure can be traced instead of defended by seniority.

In Fleetera this is the modeling half of Fabric. 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. Bindings can be suggested: point Fleetera 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.

That approval step is not ceremony. A binding is an assertion about physical reality, and a wrong one is far more damaging than a missing one, because a missing signal is visibly absent while a wrong one produces a believable number indefinitely.

Usually not, and a vendor who tells you otherwise is describing a migration project rather than an architecture. The three sit at different points and the sensible arrangement is layered.

Each row has a reason behind it. The historian is the control room's instrument and is trusted there, so its local history is not something to move for the sake of moving. The need the lake serves does not disappear when a model exists, and data science teams will keep wanting the unopinionated copy. The fabric is added rather than swapped in because it is the only one of the three whose value grows with the number of sites rather than being flat per site.

What the fabric does displace is a category of work rather than a system: the per-site integration, the export-and-merge script, the mapping spreadsheet, and the recurring conversation about why two sites disagree. Those have a cost that is rarely on anyone's budget line, which is exactly why it is so easy to keep paying it.

Often enough that it is worth saying out loud. The value of a fabric comes from repetition across sites and assets, so where there is no repetition there is little to gain and a real cost to pay.

• One site, one vendor, one protocol, and no plans to add another. A historian plus reporting will do this well and a fabric adds a modeling step whose payoff never arrives.
• A single question you need answered once. An export and a spreadsheet is the correct engineering. Building a semantic layer to answer one question is the expensive version of the same afternoon.
• Control-room latency requirements. A fabric is an analytical layer. Anything on the critical path of a control loop belongs in the control system, not in an analytics stack, and no amount of good architecture changes that.
• Data you genuinely do not understand yet. The modeling step forces a decision about meaning. If nobody yet knows what a signal means, land it in a lake, work it out, and model it when you know.
• An organization with no owner for the model. A semantic layer that nobody maintains decays into a stale mapping, and a stale mapping is worse than no mapping because people still trust it.

The semantic layer decides what a number means. It still has to sit on storage, and industrial time series has an awkward shape for storage: enormous volume, high value for the recent slice, and a long tail that is queried rarely but must exist for reporting and warranty questions years later.

Storing all of it at full resolution forever is possible and expensive. Storing only the recent slice is cheap and leaves you unable to answer the question that eventually matters. So the usual answer is three tiers: recent data at full resolution in a store built for time series, older data rolled into aggregates, and the oldest kept in a cold archive.

What the table cannot carry is the seam. In Fleetera, asking for an asset, variable and time range is a single query: the engine picks the right tier automatically and stitches hot and cold data into one result.

One consequence is worth planning for rather than discovering. 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, deliberately. If an analysis three years from now needs second-level data, that has to be a decision made now, not an assumption made then.

The demos all look similar, because they are all demonstrating the finished state on data that has already been modeled. The differences show up in what it takes to get there and in what happens when reality is untidy. A short set of questions separates them faster than a feature matrix.

None of these is a trick question, and a good product has good answers. The point of asking them is that they are all questions about the parts of the system a demo does not show, which is where the difference between an architecture and a slide actually lives.