Connect FactoryTalk Data Logger to OpenAI
You're building an OpenAI Assistants agent or a Custom GPT that should answer questions about production equipment — and the data lives in FactoryTalk Data Logger, writing to SQL Express databases on HMI workstations across the plant floor. Unlike a centralized historian, Data Logger scatters data across multiple isolated SQL instances. OpenAI function calling needs an HTTPS endpoint the model can reach from the cloud — and that endpoint has to handle schema joins, aggregation, and cross-instance queries that SQL Express can't provide directly.
The barriers below are what makes this integration harder than it looks.
Why it's hard
Seven reasons connecting an OpenAI agent to FactoryTalk Data Logger is harder than expected.
Function calls need an HTTPS endpoint — Data Logger stores to SQL Express with no REST API
OpenAI Assistants and Custom GPT Actions retrieve data by calling HTTP endpoints defined in function schemas or OpenAPI specs. FactoryTalk Data Logger has no HTTP interface — it writes to SQL Express tables on the local HMI workstation. Getting data from Data Logger into an OpenAI function call requires an intermediary that bridges SQL Express to an HTTPS endpoint that OpenAI's infrastructure can reach.
SQL Express is on HMI workstations — OpenAI calls from its own cloud
HMI workstations sit on the OT network and are isolated from the internet. OpenAI's function calling infrastructure makes HTTP calls from OpenAI's servers — it has no path to SQL Express running on a machine behind an OT firewall. Establishing that connection would require opening inbound network paths from the internet to plant floor workstations, which most OT security policies forbid.
Two-table schema requires joins the model can't perform
Data Logger uses a tag definition table and a separate values table. A meaningful response to an equipment question — pairing a tag name with a value and timestamp — requires joining both. If the function endpoint exposes raw SQL Express query results from either table alone, the model receives either anonymous numeric IDs or tag names without values. The join logic must live inside the endpoint, not in the model's reasoning.
High-frequency raw rows fill the context window
Data Logger typically records at sub-second or per-second intervals. A function returning raw Data Logger history for even a short time window sends thousands of rows back to the model. This fills the context window rapidly, increases token costs, and degrades response quality — the model spends its attention budget on raw numerical data rather than on answering the question. The endpoint must aggregate before it responds.
SQL Express 10 GB cap produces silent data gaps
SQL Express caps database size at 10 GB. When a Data Logger database fills, logging stops silently — no errors, no alerts. The agent querying against a full database returns results that appear complete but are missing recent history. Without active monitoring and rollover management, any historical query may produce an incomplete and misleading result.
Multiple Data Logger instances mean no single function endpoint
Distributed plants run one Data Logger instance per HMI workstation or per control area — each a separate SQL Express database on a separate machine. An agent that answers questions across the plant needs data from all instances. One function definition can't cover multiple isolated endpoints. Either you maintain a separate function per machine, or you build a query aggregation layer — neither is straightforward.
Custom GPT Actions require a public OpenAPI spec
Custom GPTs retrieve data using Actions defined by an OpenAPI spec hosted at a public URL. Building a spec that accurately describes tag discovery, value retrieval, and aggregated history for Data Logger data — while keeping that spec maintained as the underlying schema evolves — adds documentation and infrastructure overhead that compounds across multiple Data Logger instances.
What teams usually try
REST wrapper on the OT network querying SQL Express
Build a service with access to HMI workstations. It queries Data Logger tables, joins tag and value data, aggregates results, and exposes an HTTPS endpoint. Define the OpenAI function schema against this endpoint.
The catch: The service runs inside the OT network and needs an internet-accessible path from OpenAI's cloud. Opening that path is a security issue most OT teams won't accept. Each Data Logger instance requires a separate connection. SQL Express schema quirks, version differences, and the 10 GB cap all need handling in the wrapper.
ETL from SQL Express to a cloud database
Run scheduled extracts from each Data Logger instance to a cloud database. Point the function schema at the cloud database endpoint. OpenAI calls the cloud — no plant floor network path required.
The catch: The agent answers questions about a snapshot, not live data. ETL pipelines for multiple instances add infrastructure complexity. Schema mapping from Data Logger's two-table layout to the cloud target requires careful design. The 10 GB cap still silently breaks ETL source completeness.
Export Data Logger history to files, upload to Assistants
Export Data Logger data to CSV files and upload them as Assistants file attachments. The model reads file content to answer equipment questions.
The catch: High-frequency Data Logger exports produce files with tens of thousands of rows. File retrieval in Assistants has limits, and chunking across a large file degrades answer accuracy for time-based queries. The agent answers questions about exported snapshots — not live or recent equipment state.
How TrendOps solves it
TrendOps Edge connects to FactoryTalk Data Logger on the plant network — joining tag and value tables, handling SQL Express connections, and normalising data across all instances — and forwards structured data to TrendOps Platform in the cloud. Your OpenAI agent calls TrendOps Web API as a function endpoint or Custom GPT Action. No SQL Express connection from OpenAI's cloud, no HMI workstation exposure, no raw row dumps filling the context window.
The function schema or OpenAPI spec points to TrendOps Web API — a cloud-accessible HTTPS endpoint. No SQL Express driver, no HMI workstation connection, no plant floor network path from OpenAI's infrastructure.
TrendOps Edge performs the join on the OT side. Function responses include named tags alongside their values — the model doesn't receive raw numeric tag IDs it has to resolve.
TrendOps aggregates Data Logger history server-side before responding. Function returns interval summaries — not thousands of per-second rows that exhaust the context window and drive up token costs.
TrendOps normalises data from all connected Data Logger instances into a single platform. One function definition covers the whole plant — no separate schema per workstation.
TrendOps Edge reads Data Logger continuously. Function responses return current equipment values — not a snapshot from a periodic export or ETL job that ran on a schedule.
TrendOps Edge pushes data out over a single outbound MQTT connection. No inbound path from OpenAI's cloud to HMI workstations. The agent's function calls never touch the plant floor network.
What you end up with
No connection to HMI workstations — the agent calls a cloud API, not SQL Express on the plant floor.
Current equipment values — the agent knows what's happening right now.
Joined, aggregated responses — no raw SQL rows flooding the context window.
One endpoint, every OT source — not limited to Data Logger.
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 Data Logger equipment 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 direct access to HMI workstations to answer a question about equipment data
TrendOps gives your OpenAI agent a clean function endpoint for FactoryTalk Data Logger — joined, aggregated, and available without touching the plant floor network.
Book a Demo