The Historian Federation Gap: What Cross-Vendor Plant Data Costs Small Integrators
By Yves Habchy · July 2026
What I'm looking at
I am a software engineer. I am not a plant engineer, not a control-systems engineer, and I have never commissioned a SCADA install. I am writing this because I have been spending time inside a specific corner of the industrial-automation world, and I want to check my read against people who live in that corner.
The corner is this: in most US mid-market manufacturing plants I have looked at, the process historian data lives in two, three, or four different proprietary formats across the same facility. A packaging line running Rockwell talks to a FactoryTalk Historian SE archive. An extruder line on Siemens writes to WinCC. A legacy zone still runs Wonderware InSQL. A greenfield project two years ago picked Ignition and dropped its history into a SQL bridge. Each of these historians has its own tag ontology, its own query API, its own quirks around timestamp precision and compression, and its own set of official access paths that require reading a different SDK document.
The integrators servicing those plants (5 to 100 person firms, most under 30) do the cross-vendor query work by hand, or by writing bespoke Grafana dashboards and Python ETL scripts on their own time, or by telling the plant owner it will take eleven days to complete a root-cause investigation because the timestamps in the three source databases do not line up.
I want to understand whether that pain is as structural as it looks from outside, and if it is, what the smallest useful thing an outsider could build against it would be. I am publishing this because I want to find integrators and consultants who feel that specific pain, to compare notes with them, and because the next step involves shipping code that only makes sense if the pain is real.
What the industry says about itself
The first thing that struck me is how long the same conversation has been running in the same places. On the Inductive Automation community forum, the founder of Inductive Automation, Carl Gould, responded to a 2010 thread about extracting data from a Wonderware historian with this:
"I don't have any experience with this file format. I'm guessing its some sort of proprietary Wonderware file format?"
That quote is over fifteen years old. I include it with that fact stated, because the point is not that it is fresh, it is that the same question shape shows up in the same forum across the years since. In 2024 an integrator named zacslade wrote in a Wonderware-to-Ignition migration thread:
"They all either say that it should be straight-forward to script the conversion, or that they did it manually by putting two spreadsheet exports side-by-side and pasting data over. The person who did it manually said it took a couple of weeks of repetitive work for 15 years of data."
In a different thread about using Ignition to read from a Wonderware/AVEVA Historian, an integrator named claude.hager described the operator-facing shape of the same problem:
"Is there some other way that could expose my WWH tags automatically to my engineers and techs so they don't need me to write a new query every time they need something? Right now I'm generating wide queries with SQL and then parsing out the individual tags into memory tags. Obviously that is non-browsable by our engineers and techs."
A community member named brandon1 replied:
"Unfortunately there is no 'Out of the box' method to do this."
The FactoryTalk / OSIsoft PI side of the same pain reads the same way. In a 2025 thread about importing FactoryTalk Historian data into Ignition, an integrator named MC2338 wrote:
"The goal is to completely eliminate this old DB, but the data is valuable and referred to quite frequently... the suggested method as of now is to manually import through scripting but i believe this would be incredibly tedious (1000s of tags)."
A responder named Cody_Morgan added a specific technical constraint that turns out to matter for anything an outsider would build in this space:
"Pretty sure you can't use custom AFSDK applications with FT. IIRC, AFSDK applications must some sort of license/product code to connect to Rockwell FT PI."
The scale of the data these threads describe is real. In a separate 2025 FactoryTalk-to-Ignition migration thread, an integrator named matt6 wrote:
"A day's worth of data for all 2000 tags and it was a 400MB export file, which is wild... Some of these datapoints are collecting at 1-sec intervals, so yeah it's huge."
And a colleague named Matthew.gaitan on the same thread:
"I do not recommend using PI Datalink or PI SMT to export bulk tag data, I have had both crash."
On a separate forum, Control.com, an integrator named RRRancher wrote about Wonderware licensing in a way that shows the friction is not just technical:
"Depending on the number of devices to which you need to connect, the licensing can cost more than the OPC server software itself."
Nine quotes across five threads, sourced to named community accounts on public forums. The oldest is 2010. The newest is 2025. The shape of the pain has not changed in the fifteen years between.
What I think is going on
The public thing that has changed in the last twelve months is that AI-agent access to industrial data has become a first-class question for every major SCADA vendor. Inductive Automation announced an MCP module for Ignition at the 2025 Ignition Community Conference, went to Early Access in February 2026, and is bundling it inside an existing solution suite. AVEVA announced MCP integrations for the PI System at AVEVA World in May 2026, with Mitsubishi Heavy Industries as the partner-implementer. The OPC Foundation announced in April 2026 that it is converting its 430+ Companion Specifications into RAG and MCP-optimized formats.
Every one of those announcements is platform-native. Ignition MCP exposes Ignition. AVEVA MCP exposes AVEVA PI. The OPC Foundation work makes OPC UA MCP servers easier for everyone, which is important but sits at the live-tag layer, not at the historian-archive layer.
None of them federate across the mixed-vendor plant. And I do not expect any of them to, because it is not in their commercial interest to write high-fidelity adapters for their competitors' proprietary historians. The single-platform MCP is a natural product decision for each of them, and it leaves the cross-vendor semantic layer structurally unaddressed.
The middleware tier that could plausibly address this (AVEVA PI System itself with its Adapters, Cognite Data Fusion, Seeq, Element Analytics) sits at $50,000 to $300,000+ per year, is sold through certified system integrators, and takes twelve to eighteen months to deploy. That is the wrong price and wrong speed for a 20-person integrator quoting a scoped engagement to a manufacturer with three plants and six historian instances.
HighByte Intelligence Hub deserves its own paragraph because it is the closest-adjacent thing to what I am describing. HighByte ships a semantic modeling layer over mixed sources at a Pro tier around $18,500 per year, which is materially different from the enterprise middleware band above. HighByte is a Unified Namespace shape, oriented toward real-time streaming and product-side ontology maintained by HighByte itself, delivered as a commercial subscription. What I am describing is oriented toward historian-archive federated queries for retrospective analysis, delivered as read-only tooling the integrator owns and can inspect, with an MCP surface HighByte does not currently ship. Historian archives have retention semantics, out-of-order backfill patterns, and vendor-specific compression (deadband, swinging door) that a UNS-first product does not currently model. HighByte could add historian adapters and the modeling for them, and may. What I am observing is a timing gap in the current product surface, not a structural moat. If your plant needs a live unified namespace across streaming sources today, HighByte is an honest recommendation. If your plant needs to answer historical questions across mixed-vendor archives with an open-source query layer an AI agent can consume, HighByte does not currently do that job.
The gap I think is real is a specific one. It is not "cross-vendor SCADA is unsolved." It is: there is no cross-vendor historian federation layer designed for small-firm integrators, priced at the services-engagement tier they actually buy at, delivered as tooling they own and can inspect. The transport layer under it (KEPServerEX, OPC UA) is already commodity. The historian archives above it (PI, InSQL, Proficy, Ignition history) already exist and are already the source of truth. The gap is the semantic and query layer that sits between them and lets an engineer, or an AI agent operating on that engineer's behalf, ask a single question that reaches into all four.
What watching actually looks like
I want to make the shape concrete because "cross-vendor federation" is the kind of phrase that means everything and nothing. Here is one workflow, described the way an integrator on the Ignition forum would describe it:
An OEE dip shows up on a report Monday morning. The plant manager wants to know why the packaging line ran below target on Friday's second shift. The integrator knows that answering that question means pulling motor-current from a Rockwell PLC through FactoryTalk Historian SE, product-changeover events from a Wonderware InSQL archive on the labeler, temperature from a Siemens WinCC store on the extruders upstream, and downtime codes from an Ignition SQL bridge on the greenfield section.
Four historians, four query APIs, four tag naming conventions, four time bases with different compression settings. Today that engineer opens four applications, exports four CSVs, and lines them up in Excel. If the plant is lucky, an intern spent a summer three years ago building a Grafana dashboard that partly automates the first three, and it still works most days. If the vendor recently pushed a firmware update, it does not.
An MCP-shaped federation layer would let the engineer or an AI agent write a single semantic query: "get me packaging line 2 motor current, product changeovers, upstream extruder temperature, and downtime codes for Friday second shift, aligned to a common time base, tagged by asset." The transport hits four historians through their own official APIs (PI Web API for the PI-backed archives, SQL for InSQL, WinCC's own paths, Ignition's tag history query for the SQL bridge). The semantic layer maps four vendor tag ontologies to one asset-and-signal ontology the engineer maintains for that plant. The MCP surface makes the whole thing consumable by Claude, ChatGPT, or a local agent inside a Grafana panel.
The scoped engagement, when I imagine it, is not a subscription. It is a two-to-four week piece of work: install, configure the adapters against the specific historians the plant actually runs, help the integrator's own team build the plant-specific asset ontology, hand off an open-source repo and a paid-support relationship. Same shape a small integrator already buys and sells.
There is a tension in that framing worth naming directly. The MCP transport and adapter layer is reusable across plants and lives as a product. The per-plant asset ontology is bespoke every time and lives as consulting work. Both are load-bearing. The business is services-engagement economics with an open-source product underneath, not product economics with a services wrapper. The scoped engagement is where revenue lives; the open-source repo is unpaid infrastructure that supports it. Pricing follows integrator-market norms for a two-to-four week scoped build. That is the honest shape, and it matches how small integrators already buy tools like this.
I am specifically not writing about the CONTROL side of this. Setpoint writes, PLC writes, anything that touches the actual process, sits behind functional-safety review (IEC 61508, IEC 61511) and insurer conditions that a first-cycle outsider has no business near. What I am describing is read-only: federated queries and AI-agent inspection of historian data that already exists.
Honest constraints
Six things I want to be transparent about, because they matter for whether the conversation I am asking for is worth anyone's time.
-
I do not have plant-floor experience. I have not commissioned a system, I do not hold an ISA or CSIA or Rockwell certification, and I have never sat in a control room during a real event. Everything I know about how this workflow feels I know secondhand from the forums, from published integrator methodology posts, from the trade press, and from talking to two people so far. I am writing this to find more people to talk to, not to claim I already know their job.
-
My sourcing is public-forum and vendor-documentation, not field research. The nine quotes above are all from Inductive Automation's own community forum and from Control.com. I chose those because the accounts are named, the threads are public, and the vocabulary is first-person integrator, not editorial paraphrase. But it is a specific slice: it skews toward integrators who work at least partly with Ignition, because that is where the migration and federation questions surface. I have not yet gotten access to PLCtalk at the level I want (their user agreement is clear about what they permit and my current standing there is a new-account, comment-first phase). I have not done systematic reading on control.com beyond a handful of threads.
-
One of the quotes is old and I want to name that. Carl Gould's 2010 comment is fifteen years old. I include it as evidence that this specific question has been continuous in the same forum for that long, not as evidence of current state. The 2024 quotes from zacslade, MC2338, matt6, Matthew.gaitan, and Cody_Morgan describe the same shape at present tense, and those are what I would consider load-bearing for current conditions.
-
The technical path I am pursuing routes around one specific incumbent constraint. Cody_Morgan's note about the FactoryTalk AFSDK license gate is the reason I am writing this against the PI Web API (REST) path rather than the AFSDK path for FactoryTalk Historian SE and OSIsoft PI. That trades some structured-data fidelity for a cleaner distribution posture. It is a first-cycle decision, not a permanent one. The route-around assumes PI Web API on FactoryTalk Historian SE is not similarly license-gated; the public docs suggest it is a REST layer that does not require AFSDK product codes, but I have not verified this on a live FT install, and it is one of the first things I would want to confirm with an integrator who has access.
-
The scope is deliberately narrow at the start. I am not planning to build against every proprietary historian on day one. The first pass covers FactoryTalk Historian SE and OSIsoft PI (both PI Web API), Wonderware InSQL (SQL), and the Ignition SQL bridge (SQL). WinCC, Proficy, and the smaller archives come later, in an order that customer conversations should decide, not I should.
-
The vertical scope is narrower than "industrial." I am specifically not looking at chemical processes covered by OSHA PSM, at pharma covered by FDA 21 CFR Part 11, or at grid operations covered by NERC-CIP. The regulatory surfaces on those are not something an outsider at my stage of this work should be near. I am looking at US mid-market discrete manufacturing (food and beverage, auto parts, packaging, materials) and industrial data-center OT. If your work is inside the excluded scope, I am happy to talk about the general shape but I am not going to try to do work there yet.
The ask
If you are a principal or a senior engineer at a US mid-market SCADA / DCS / PLC integrator firm (roughly 10 to 100 people), or a solo consultant serving mixed-vendor plants in the same scope, and any of the workflow above reads like a Friday you have had, I would appreciate a conversation.
I am not selling a product. I do not have pricing, a waitlist, or a demo. What I have is a research read on a specific gap, a plan for a small piece of tooling I want to build against it, and a set of open questions about how integrators in this space actually buy tools like this, what the price and shape of a scoped engagement should look like, and which of the historian formats hurts the most on live jobs today.
I am also happy to trade. If you talk to me for thirty minutes I will share the aggregated patterns I have seen across every conversation I have had so far, with names and firms stripped out. If it turns out there is a piece of this work that would be useful to your team, we can talk about a scoped engagement. If it turns out I am wrong about the gap, that is the most useful thing you could tell me, and I want to hear it.
Yves Habchy · LinkedIn · yves.habchy@gmail.com · habchy.dev