Connect AVEVA Wonderware to OpenAI
You're building an OpenAI agent or Custom GPT that should be able to answer questions about plant operations — and the process data lives in AVEVA Wonderware Historian. OpenAI's function calling expects cloud-accessible REST endpoints. Wonderware exposes data through IndustrialSQL Server — a proprietary SQL interface on a private OT network that has never been intended to answer calls from an AI model running in OpenAI's cloud.
The barriers below are the ones that stop most teams before they get a working prototype. They're not in the OpenAI documentation because the problem is on the Wonderware side.
Why it's hard
Seven reasons connecting an OpenAI agent to AVEVA Wonderware is harder than writing a function definition.
OpenAI function calls need a cloud REST endpoint — Wonderware exposes IndustrialSQL
When an OpenAI assistant calls a function, your application makes an HTTP request to an endpoint and returns the result. Wonderware's query interface is IndustrialSQL Server — accessible via ODBC, not HTTP. Before any function can retrieve Wonderware data, something has to bridge from IndustrialSQL to a REST interface that cloud code can call.
IndustrialSQL is on the OT network — your application server can't reach it from the cloud
Even if you build a REST wrapper, it needs to run somewhere with access to IndustrialSQL — which means it runs on the OT side of the network. Your cloud-hosted application then needs a path to that wrapper: a reverse proxy, a VPN, or a DMZ endpoint. Each of these requires security approval and introduces a point of maintenance that must stay operational for every agent query.
IndustrialSQL retrieval modes produce different results — the wrong one breaks the function response
Querying IndustrialSQL correctly requires choosing a retrieval mode: cyclic returns values at fixed intervals, delta returns only changed values, interpolated fills gaps. A function that queries with the wrong mode returns misleading data — delta queries return sparse results the model interprets as missing data; cyclic queries at high frequency return thousands of rows. The retrieval logic has to live in the integration layer, not in the agent.
ODBC driver required — can't run on any cloud-side component
Accessing IndustrialSQL requires the Wonderware ODBC driver installed on the machine making the query. Cloud-hosted application servers can't install proprietary ODBC drivers. The query has to originate from on-premise infrastructure — which means you can't make the IndustrialSQL call from a serverless function or cloud-hosted API without a relay.
Wonderware tag names are opaque — function responses need readable context
Wonderware tag names encode equipment and signal hierarchies that are meaningful only to the people who configured the system. A function response that returns a raw tag name alongside a numeric value gives the model nothing to work with. Without descriptive names, engineering units, and process context in the function response, the agent either guesses at what values mean or returns unhelpfully vague answers.
Raw IndustrialSQL history queries return enormous row counts
Wonderware Historian can store data at high frequencies across hundreds of tags. An unfiltered history query for even a short time window can return thousands of rows. Function responses of that size consume a large portion of the model's context window, crowding out the conversation and making multi-step queries expensive. Server-side aggregation is essential before data reaches the function response.
Custom GPT Actions require a public OpenAPI spec for a clean endpoint
If you're building a Custom GPT, the integration mechanism is Custom GPT Actions, which require an OpenAPI 3.x spec for a publicly accessible endpoint. IndustrialSQL has no built-in OpenAPI interface. You need to design a purpose-built, agent-friendly API — not just expose IndustrialSQL as-is — which means the full middleware build before you can write a single line of the Custom GPT configuration.
What teams usually try
Three approaches — and where each one runs into trouble.
Build a REST wrapper on the OT network, function calls hit it
Write a small service on a machine with ODBC access to IndustrialSQL. It queries Wonderware and exposes REST. Define OpenAI functions against this endpoint, either for the Assistants API or as Custom GPT Actions.
The catch: The wrapper runs on OT infrastructure and needs to be exposed to the cloud — a security decision most OT teams won't approve. Every Wonderware upgrade that affects schema or retrieval behaviour is another code change. You've built a custom integration for one historian.
ETL to a cloud database, functions query the cloud
Run a scheduled extract from Wonderware into Azure SQL or a cloud data store. Define OpenAI functions against the cloud database. No OT network path required from the function execution environment.
The catch: The agent answers questions about past snapshots. "What is the current pressure?" becomes "What was it as of the last extract?" The ETL pipeline needs to run reliably, and schema mapping between IndustrialSQL and the cloud store requires ongoing maintenance.
Upload exports to a vector store, use file search
Export Wonderware data periodically, embed and upload it to an OpenAI vector store. The assistant retrieves chunks by semantic similarity rather than making live queries.
The catch: Time-series process data doesn't benefit from semantic similarity search. The assistant answers questions about stale file contents. Export volume for large historians produces files that are too large to upload reliably on any reasonable schedule.
How TrendOps solves it
TrendOps Edge connects to AVEVA Wonderware on the OT network — handling IndustrialSQL queries, retrieval mode selection, and ODBC connectivity on-premise — and forwards normalised, context-rich data to TrendOps Platform in the cloud. Your OpenAI agent defines functions that call TrendOps Web API. No ODBC driver, no OT network path, no IndustrialSQL retrieval mode logic in the function layer.
Function calls go to TrendOps Web API — a cloud-accessible HTTPS endpoint. No ODBC driver, no on-premise relay, no security exception into the OT network required.
TrendOps Edge manages ODBC connections, retrieval mode selection, and query execution against IndustrialSQL. Function responses are clean and consistent — no retrieval mode logic required in the agent layer.
TrendOps handles aggregation server-side. Function responses return compact, interval-based summaries — not raw IndustrialSQL row dumps that fill the context window.
TrendOps resolves Wonderware tag names and surfaces engineering units alongside values. The model receives context it can use to answer accurately — not raw tag strings it has to guess the meaning of.
TrendOps Edge polls Wonderware Historian continuously. Function calls return live values — not a snapshot from a scheduled extract that ran last night.
TrendOps normalises data across all connected historians. The same function definitions work whether the data comes from Wonderware, AVEVA PI, DeltaV, or SQL — no separate function set per historian.
What you end up with
Functions call a standard REST API — no ODBC driver, no IndustrialSQL exposure.
Current process 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 Wonderware.
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 Wonderware 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 an ODBC driver and an OT relay to answer a question about plant data
TrendOps gives your OpenAI agent a clean, cloud-accessible API for AVEVA Wonderware data — with descriptive names, aggregated history, and no IndustrialSQL in the call path.
Book a Demo