Connect FactoryTalk Historian to OpenAI
You're building an OpenAI agent or Custom GPT that should be able to answer questions about production operations — and the process data lives in Rockwell's FactoryTalk Historian. FactoryTalk Historian runs on the same PI engine as AVEVA PI, which means OpenAI's function calling faces every barrier that makes PI-based historians hard to connect to cloud AI: proprietary data model, on-premise OT network isolation, SDK dependencies, and no REST interface that a cloud-hosted function can reach out of the box.
The barriers below are the ones where most teams stall before they have a working agent.
Why it's hard
Seven reasons connecting an OpenAI agent to FactoryTalk Historian is harder than writing a function definition.
OpenAI functions need a cloud REST endpoint — FactoryTalk Historian speaks PI protocol
When your agent loop executes a function, it makes an HTTP call to an endpoint and returns the result. FactoryTalk Historian's native interface is the PI Server protocol, accessible through PI AF SDK or PI Web API — neither of which is reachable by cloud application code without significant additional infrastructure. PI Web API is the closest option but requires explicit deployment and OT-side configuration.
PI Web API is on the OT network — your application can't reach it from the cloud
Even if PI Web API is deployed, it sits on a private OT VLAN that your cloud application cannot reach. Function execution happens wherever your application runs — if that's a cloud-hosted service, it has no path to an OT-side PI server. Getting that path requires either exposing PI Web API to the internet or running your application inside the OT network, both of which introduce significant security and operational concerns.
PI AF SDK required for context — but it can't run in a cloud environment
PI Asset Framework gives raw PI tags their operational meaning — descriptive names, units, hierarchy, and normal ranges. Retrieving AF context requires the PI AF SDK, a Windows-only on-premise component with a Rockwell license. Cloud application environments can't install it. Without AF context, function responses return raw tag names and numeric values that the model can't interpret or explain meaningfully.
Raw PI data floods the context window
FactoryTalk Historian stores data at high frequencies. A function call that returns unfiltered PI history for a time range returns thousands of data points, each consuming tokens in the model's context. For multi-step agent conversations with several function calls, raw PI responses can consume most of the available context window before the model has a chance to reason about the data.
FactoryTalk tag names are meaningless without AF context
PI tag names encode control system and instrument conventions — strings like "Compressor_1.FT201.Flow.PV" that are shorthand for a specific measurement on a specific piece of equipment. Without AF resolution, the model receives a numeric value alongside an opaque identifier and has no way to tell the user what it represents — or whether it's normal.
Custom GPT Actions require a clean OpenAPI spec — PI Web API's isn't designed for it
Building a Custom GPT requires a Custom GPT Action with an OpenAPI spec for a publicly accessible endpoint. PI Web API has its own OpenAPI spec, but it's complex, not designed for LLM consumption, and exposes far more surface than you want an agent calling. You need a purpose-built, simplified API — which means the full middleware project before you can configure the Custom GPT.
Multi-site deployments mean multiple PI servers with separate namespaces
Larger Rockwell deployments run separate FactoryTalk Historian servers per facility. Each has its own tag namespace and connection. An agent that needs to answer cross-site questions — comparing production between plants, for example — needs either separate function sets per server or an aggregation layer that presents a unified namespace. Neither is trivial to build.
What teams usually try
Expose PI Web API as the function endpoint
Deploy PI Web API, expose it through a DMZ or reverse proxy, then define OpenAI functions that call it directly. The most direct route to PI data from a cloud agent.
The catch: Exposing PI Web API to the internet is a security decision most OT teams won't approve. The PI Web API response schema isn't designed for LLM consumption. Raw compressed PI responses fill the context window. Every Rockwell Automation upgrade risks breaking the schema.
Custom middleware with PI AF SDK on-premise
Build a REST service on an OT-side machine with PI AF SDK installed. It queries FactoryTalk Historian, resolves AF context, and exposes a clean API that cloud-based OpenAI functions can call.
The catch: Custom middleware running on OT infrastructure needs to be built, licensed, hosted, and maintained. It requires Rockwell PI licensing. Every PI version upgrade that changes SDK behavior is a potential breaking change.
Upload PI data to a vector store
Export FactoryTalk Historian data periodically, embed and upload to an OpenAI vector store. The assistant uses file search rather than live function calls to retrieve process information.
The catch: Time-series process data doesn't benefit from semantic similarity search. The agent answers questions about stale exports. For large deployments, export files are too big to upload reliably and too large for the vector store to index usefully.
How TrendOps solves it
TrendOps Edge connects to FactoryTalk Historian on the OT network — using PI AF SDK on-premise to resolve asset context before data leaves the plant — and forwards normalised, context-rich data to TrendOps Platform in the cloud. Your OpenAI agent defines functions that call TrendOps Web API. No PI SDK in the cloud, no raw PI schema to parse, no context window flooding from bulk historian dumps.
Function calls go to TrendOps Web API — a standard HTTPS endpoint. No PI AF SDK or PI client software required on any cloud component. No internet-facing PI server.
TrendOps Edge resolves PI AF context on-premise before data leaves the plant. Function responses include descriptive names, engineering units, and asset context — not raw PI tag strings.
TrendOps handles aggregation server-side. Function responses are compact interval-based summaries — not raw compressed PI values that fill the context window with numbers the model can't summarise.
TrendOps normalises data from all connected FactoryTalk Historian instances. Functions query across sites through one endpoint — no separate function sets per server.
TrendOps Edge polls FactoryTalk Historian continuously. Function calls return current values — not a snapshot from a scheduled export that ran last night.
TrendOps Edge pushes data out over a single outbound MQTT connection. OpenAI function calls terminate at TrendOps Platform — never at the plant network.
What you end up with
Functions call a standard REST API — no PI client software on any cloud component.
Current production values — the agent answers real-time questions accurately.
OpenAI calls TrendOps cloud API — the OT network is never in the function call path.
One function set, every OT historian — not limited to FactoryTalk.
Don't want to build your own AI agent integration?
TrendGuru — TrendOps's built-in AI agent — already has access to your plant data. Ask questions about your FactoryTalk Historian in plain language and get answers instantly, deployed directly in Microsoft Teams. No function definitions to write, no OpenAPI spec to maintain, no token costs to manage.
Learn about TrendGuru →Your OpenAI agent shouldn't need a PI developer on standby to answer a question about production data
TrendOps gives your OpenAI agent a clean, cloud-accessible API for FactoryTalk Historian data — with AF context, aggregated history, and no PI SDK in the cloud.
Book a Demo