The AI built the plumbing, then couldn't find the plant

I did not draw the pipeline. I was in another window talking to a model over a socket, and when I refreshed the browser there was a pipeline on the canvas called AiBuiltPipeline. Nobody had clicked anything.

That is the moment worth reporting from this lab, and the uncomfortable half belongs right next to it: the same interface that let an AI build plant plumbing could not tell me which of my heat exchangers had a low temperature differential. Not because it answered badly, but because the data was structurally invisible to it. Both things are true about the same product on the same afternoon, and between them they describe the category better than any brochure does.

The problem this software exists to solve#

If you have ever sent plant data to a corporate analytics team you know how the conversation goes. Getting the numbers out is the easy part, because OPC UA and MQTT solved that years ago. What arrives at the far end is ten thousand series called things like PLC1_AI_0042.

Nobody at that end can tell you which pump that is, what unit it is in, whether a zero means the value is zero or the transmitter is dead, or whether the tag called Flow_1 at the Rotterdam plant is measured the same way as the Flow_1 at Houston. So somebody spends the first six months of the project rebuilding, in Python, the context the controls engineer had in their head the whole time, and then the next project starts and somebody rebuilds it again, slightly differently.

Industrial DataOps is the argument that this context should be built once, in a layer of its own, versioned and governed, and reused by everything downstream. HighByte Intelligence Hub is the most fully formed product making that argument. IDC named it a Leader in its first assessment of the category in March, and on 3 June Siemens announced a partnership putting the Hub on Industrial Edge, which is about as strong a distribution signal as this corner of the industry produces. So I ran it against real moving data to find out how much of it holds up.

The rig#

The Hub runs as a Docker container. It is a Java application with no cloud tenancy and nothing to install on a controller, and the trial is fully functional with a two-hour runtime clock you reset when it expires. That turns out to be an honest way to license lab software: nothing is crippled, but you cannot quietly run production on it.

For sources I gave it two things worth connecting to. A live OPC UA connection into the Ignition gateway from an earlier lab, so there was genuinely moving process data rather than a static file, and a TimescaleDB connection so there was somewhere real for data to land.

Browsing the gateway and pulling a branch in as an input took about a minute, and the built-in test view reads it live, which is the sort of small thing that decides whether a tool is pleasant to work in.

Then I worked through the five things the product claims, in order.

Models are the actual product#

A model is a typed definition of an asset: attributes with names, data types, units and descriptions, so a pump has a suction pressure in bar, a discharge pressure in bar and a flow in cubic metres an hour.

If you have used Ignition UDTs this will feel familiar and it should. The difference is what you are allowed to build out of them. A Simple model is flat attributes, a Modeled attribute lets a model contain another model, which gives you composition, and an Object type gives you hierarchy, so a plant contains stations, a station contains heat exchangers, a heat exchanger has attributes, and that whole shape is one definition you can stamp out.

Worth saying plainly that the tool does not do this work for you. It gives you somewhere disciplined to put it. That sounds like faint praise and is not, because most sites keep this knowledge scattered across a P&ID, a naming convention nobody wrote down, and two engineers.

Instances: where several sources become one thing#

An instance is a model bound to real data, and binding is drag and drop. You pull a live input onto an attribute and it wires up.

The capability that justifies the whole layer is that one instance can pull from several sources at once. Flow comes from the PLC over OPC UA, nameplate data comes from a SQL table, the current work order comes from a REST call to the maintenance system, and all three arrive downstream as one coherent object.

I bound an instance to live Ignition inputs and watched the merged payload resolve in the test view. It works, and this is the capability I would actually miss if you took the product away, because writing that join by hand is a week of somebody's life per asset type and it never gets written the same way twice.

Pipelines, and the Parquet tell#

The pipeline canvas is a visual ETL builder with around thirty stage types: JavaScript and JSONata transforms, read and write stages, model and validation stages, a query stage, switches, loops, buffers, and parsers and formatters for CSV, JSON, XML and Parquet.

That Parquet stage tells you who the product is for. Parquet is a data-lake file format and nobody on a plant floor has ever asked for it. The design target is the warehouse, and the honest reading of the whole product is that it exists to make plant data acceptable to the people who own the lake.

Namespaces, and why this is the strong bit#

Version 4.0 added Namespaces and this is the most defensible idea in the product.

Most Unified Namespace deployments in the wild were never designed. Somebody picked a topic structure, typed it into the broker, and it grew from there. An undesigned UNS is MQTT with extra steps and a nicer name.

HighByte makes the namespace a real artifact: a tree you lay out deliberately, a query builder that lets you ask the namespace questions instead of remembering paths, and remote mapping so hubs at different sites can be stitched together. Version 4.4 pushes that into federated namespaces, where a central hub sees each remote hub's tree and maps it into one central view.

If you are going to buy this product, buy it for this.

The pipeline I didn't draw#

Now the part I actually came for. MCP is the standard way AI clients connect to external systems, and roughly speaking it is OPC UA's job description rewritten for AI clients instead of HMIs. It has been spreading through OT tooling all year; the N3uron lab found one, and so did the Modbus copilot I built myself.

HighByte's is different in kind. The surface splits in two, and the split is documented rather than accidental: version 4.3 added browse and read tools to OPC UA and MQTT connections, and separately added tools that let an agent create and edit pipeline configuration.

So one half is data tools, generated per connection, connection_Ignition_browse and connection_Ignition_read. Browse the tree, read values, the same shape everyone else offers. The other half is config_pipeline_schema, config_pipeline_examples, config_pipeline_get, config_pipeline_create and config_pipeline_edit. Read that list again, because those are not tools for reading plant data. They are tools for building the plant's data plumbing.

I tested it the obvious way. Ask for the pipeline schema, get back the JSON structure the product expects, construct one, call config_pipeline_create, refresh the browser.

To HighByte's credit this sits behind a Configuration Tools toggle that is off by default, and 4.4 ships the same idea as a supported in-app feature, a Pipeline AI Agent that summarises, creates and edits pipelines conversationally with a human approving each step. The version I tested already had it. What I did was reach the same capability from outside, through a generic client, with no approval step in the loop, which is a different security posture even though it is the same underlying feature.

I think this is the first mainstream industrial product where an AI can build infrastructure rather than just read from it. I also think that is exactly the sentence that ends the conversation in a lot of OT security reviews, and it should, because "an AI wrote this pipeline" needs to be something the audit log can say out loud, and I could not establish that it can.

Then I asked it about a plant#

Here is the counterweight, and it is the more useful finding.

I loaded a real estate into the Hub, thirty-five modelled heat-exchanger stations and a plant object with proper domain descriptions on every attribute, and seeded forty-eight hours of history into the connected TimescaleDB. Then I put a chat client in front of the MCP server and asked the kind of question an operator asks: which stations have a low temperature differential?

It could not see any of it. The modelled instances are not on the MCP surface. Neither is the namespace. Neither is the SQL historian, because SQL connections have no MCP toggle at all: the release notes put those browse and read tools on OPC UA and MQTT connections, and that is the whole list. The only plant data exposed was the raw simulator tree, which is sine waves.

So the honest answer to that question is a refusal. The likely answer from a confident model is that it reads the sine waves and invents something, which is the failure mode I already watched play out when a copilot reasoned carefully from bad provenance and reached a plausible, wrong conclusion.

None of this is a knock on the product. It is a category boundary, and once you see it the shape snaps into focus: this AI surface is for engineers building plumbing, not for operators asking questions. Those are different products. Anyone demoing "AI on your plant data" on top of middleware like this should be asked which one they are actually selling.

What it refuses to do#

Two constraints, both stated openly by the vendor, both more important than any feature. It does not store data; the documentation says it "intentionally does not store or analyze data", so this is not a historian and not a warehouse. And the field-driver list is deliberately thin: Modbus TCP, OPC UA, MQTT, Sparkplug and a native Ignition connection. That is the lot. No S7, no DNP3, no IEC-104, no serial.

Taken together those mean this can never be your only middleware. Something below it has to talk to the actual devices and something beside it has to keep the data. The honesty is refreshing, since plenty of products in this space imply they are the whole answer, but you have to design around it.

The price conversation#

Professional licensing is $18,500 per site per year. Three factories in a starter pack is $50,000, a data-centre aggregation point is $65,000, enterprise is bespoke, and everything is included at every tier: unlimited models and pipelines, high availability, the embedded broker, the REST server, MCP.

That is subscription pricing for a governance layer and it makes the buying decision unusually clean. If you have one plant, the layers you already own cover most of it, because UDTs give you typed assets, a broker gives you decoupling and a historian gives you retention. You would be paying eighteen and a half thousand a year for tidiness.

For a sense of how sharp the split is, the nearest neighbour in the category sells per-node perpetual licences at around €800, so a twenty-node estate there costs roughly one HighByte site-year. They are not substitutes, since one is connectivity downwards and the other is modelling upwards, but it tells you which problem you are being asked to pay for.

Where it goes in a stack#

Every argument about this category is really an argument about which layer of a stack you are buying, so it is worth drawing the stack.

Where it bleeds#

The two-hour trial clock is right for evaluation and means you cannot leave anything running, so plan sessions rather than experiments. There is no official ARM64 image, since the container is x86_64 Alpine and OpenJDK, and ARM needs a custom build, which rules out the cheap single-board edge appliance a lot of the industry has standardised on. The stated 1 GB RAM minimum is a floor for an empty project, not a running one.

And the honest scope limit on this lab: I did not test high availability, did not test store-and-forward across a broken link, did not test it at scale, and did not drive the in-app Pipeline AI Agent. What I tested was whether the headline claims are real, and they are.

Verdict#

Buy it when three things are true at once. You have several sites naming the same assets differently, you have a real consumer waiting downstream in the shape of a lake or a warehouse or an AI programme, and somebody owns the models. That last one is not optional. This is a governance tool, and a governance tool without an owner decays into a second undocumented integration layer, which is worse than not having it at all.

Do not buy it for one plant. You already own most of it.

The namespace design is the strongest thing in the category, the multi-source merge is the thing that is genuinely painful to hand-build, and the AI write-surface is the most interesting and most uncomfortable capability I have seen in an industrial product this year. A real first, shipped carefully, and one I would leave switched off until the audit log can tell me which pipelines a human actually wrote.