Connect AVEVA Wonderware to Copilot
You're building a Copilot agent that should be able to answer questions about plant operations — and the process data lives in AVEVA Wonderware Historian. The agent needs to query tag values, retrieve trends, and surface operational context. The problem is that Wonderware Historian exposes data through IndustrialSQL Server — a proprietary SQL interface that lives on a private OT network and has no path to Microsoft's cloud.
The barriers below are the ones most teams hit when they try to connect Copilot Studio to Wonderware. None of them are obvious until you're already blocked.
Why it's hard
Seven reasons connecting a Copilot agent to AVEVA Wonderware is harder than pointing a Custom Connector at it.
Copilot agents call HTTP endpoints — Wonderware exposes IndustrialSQL, not a REST API
Copilot Studio agents retrieve data through Custom Connectors, which make outbound HTTP calls. Wonderware Historian's primary query interface is IndustrialSQL Server — a proprietary SQL layer accessible via ODBC or the Historian Client SDK. There is no built-in REST endpoint for Copilot Studio to call. Before any agent can query Wonderware data, something has to translate between the two interfaces.
IndustrialSQL Server is on the OT network — Microsoft's cloud calls from outside
When a Copilot Studio agent invokes an action, the HTTP request originates from Microsoft's Power Platform cloud infrastructure — not your corporate network. Wonderware's IndustrialSQL Server sits on a private OT or historian VLAN that has no inbound path from the internet. Getting Microsoft's cloud to reach it requires deliberate, security-reviewed network engineering that most OT teams won't approve.
Wonderware retrieval modes add query complexity an agent can't navigate alone
IndustrialSQL supports multiple retrieval modes — cyclic, delta, interpolated, lab, and others — each designed for different query patterns. Choosing the wrong mode returns nonsensical data: delta mode for a trend query returns only changed values, interpolated mode fills gaps that may not exist. An AI agent has no way to select the correct retrieval mode without pre-processing logic sitting between it and the historian.
ODBC client is required — no cloud component can install it
Querying IndustrialSQL from any application requires the Wonderware ODBC driver installed on the querying machine. Cloud-based infrastructure — including Microsoft's Power Platform — cannot install proprietary ODBC drivers. Even if you had network access to IndustrialSQL, there's no driver available on the cloud side to make the connection.
Wonderware tag names are opaque without context
Wonderware tag names follow naming conventions set at system configuration time — strings like "SiteA.FIC201.PV" or "Line3.TankLevel.Out" that encode equipment and signal hierarchies meaningful only to the engineering team. A Copilot agent working with raw tag names has no way to explain what a value means to an operator asking in plain language. The agent needs descriptive names, engineering units, and process context alongside every value.
Power Platform Custom Connectors require admin approval and an OpenAPI spec
Connecting a Copilot Studio agent to any external data source requires building a Custom Connector with an OpenAPI 3.x spec — then getting it approved by a Power Platform admin before it can be used in production. If the connector points at an endpoint adjacent to OT systems, the security review adds more time. In multi-tenant Microsoft 365 environments, this process often takes weeks.
Copilot for Microsoft 365 and Copilot Studio are different products
The AI assistant built into Teams, Outlook, and Word is Copilot for Microsoft 365 — it doesn't support custom data connectors for plant data. Building an agent that can query Wonderware requires Copilot Studio, a separately licensed product with its own environment, admin requirements, and per-message or per-user pricing model that's easy to underestimate at scale.
What teams usually try
Three approaches — and where each one runs into trouble.
REST wrapper around IndustrialSQL on the OT network
Build a small service on a machine with ODBC access to IndustrialSQL. It queries Wonderware and exposes a REST API. Define a Custom Connector against this endpoint.
The catch: The wrapper needs to be hosted on the OT side, kept running, and maintained. The REST endpoint still needs a network path to Microsoft's cloud. Every Wonderware upgrade that changes schema or retrieval behaviour is another code change.
ETL pipeline to a cloud database, agent queries cloud
Extract Wonderware data on a schedule into Azure SQL or a cloud warehouse. Point the Custom Connector at the cloud database. No OT network path required from Microsoft's side.
The catch: The agent answers questions about past snapshots, not current plant state. The ETL pipeline adds infrastructure to build and maintain. Schema mapping from IndustrialSQL to the cloud database requires ongoing alignment as the historian evolves.
Export to SharePoint, agent reads files
Export Wonderware data to CSV or Excel on a schedule, upload to SharePoint, and configure the Copilot agent to search those files as its knowledge source.
The catch: File-based knowledge means stale answers. The agent can't answer "what is the current level on Tank 2?" — only "what was it as of the last export?" Large historian exports also produce files too large for SharePoint-based agent retrieval to handle well.
How TrendOps solves it
TrendOps Edge connects to AVEVA Wonderware on the OT network — querying IndustrialSQL directly with the right retrieval mode for each data type — and forwards normalised, context-rich data to TrendOps Platform in the cloud. Your Copilot Studio agent calls TrendOps Web API through a single Custom Connector. No ODBC driver, no OT network path, no IndustrialSQL complexity on the cloud side.
The Copilot agent calls TrendOps Web API — a cloud-accessible HTTPS endpoint. No ODBC driver on any cloud component, no reverse proxy pointing at IndustrialSQL, no firewall exception into the OT network.
TrendOps Edge selects the correct IndustrialSQL retrieval mode for each data type and query pattern. The agent receives clean, consistently structured responses without needing to know what cyclic or delta mode means.
TrendOps resolves Wonderware tag names and surfaces engineering units alongside values. The agent receives context it can use to give a meaningful answer — not a tag identifier that means nothing outside the engineering team.
TrendOps Edge polls Wonderware Historian continuously and keeps TrendOps Platform current. The agent returns live process values — not a snapshot from last night's export.
TrendOps Edge pushes data out over a single outbound MQTT connection. No inbound path into the OT network is required. The Copilot agent's calls never reach the plant network.
TrendOps normalises data across all connected historians. The same Custom Connector works whether the underlying data comes from Wonderware, AVEVA PI, DeltaV, or SQL. The agent doesn't need a separate connector for each historian.
What you end up with
No ODBC driver on any cloud component — the agent calls a standard REST API.
Current process values — the agent knows what's happening right now.
Copilot calls TrendOps cloud API — the OT network is never in the call path.
One connector, 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 Custom Connector to configure, no OpenAPI spec to write, no Power Platform admin approval to wait for.
Learn about TrendGuru →Your Copilot agent shouldn't need an ODBC driver and an OT network exception to answer a question about plant data
TrendOps gives your Copilot agent a clean, cloud-accessible API for AVEVA Wonderware data — so it can answer live process questions without touching IndustrialSQL.
Book a Demo