Connect DeltaV Continuous Historian to OpenAI
You're building an OpenAI Assistants agent or a Custom GPT that should answer questions about process conditions — and the data lives in DeltaV Continuous Historian, running deep inside an Emerson DeltaV DCS on a closed OT network. OpenAI function calling needs an HTTPS endpoint the model can reach from the cloud. DeltaV Continuous Historian doesn't have one — it speaks OPC, uses Emerson-specific tag addressing, and sits on network infrastructure that was designed to stay isolated from the internet.
The barriers below are what makes this integration harder than it looks.
Why it's hard
Seven reasons connecting an OpenAI agent to DeltaV Continuous Historian is harder than expected.
Function calls need an HTTPS endpoint — DeltaV Continuous Historian speaks OPC, not REST
OpenAI Assistants and Custom GPT Actions retrieve data by calling HTTP endpoints defined in function schemas or OpenAPI specs. DeltaV Continuous Historian does not expose a REST API. Data access goes through OPC DA and OPC HDA, or through Emerson-proprietary interfaces — all requiring OPC clients running on the OT network. Getting from OPC to an HTTPS endpoint that OpenAI can call requires an intermediary layer that has to live somewhere with access to both worlds.
DeltaV systems sit on closed OT networks — OpenAI calls from its own cloud
DeltaV DCS networks are air-gapped or separated from IT and the internet by strict firewall policies. OpenAI's function calling infrastructure makes HTTP requests from OpenAI's servers — it has no path to a DeltaV node on a production OT network. Establishing that connection would require opening inbound access to DCS infrastructure from the internet, which Emerson and OT security frameworks explicitly caution against.
OPC Classic uses DCOM — which doesn't cross network boundaries reliably
OPC DA and HDA use Microsoft DCOM, which requires Windows domain trust and specific DCOM port configuration to work across subnets. Getting an OPC client to query DeltaV Continuous Historian reliably from a machine outside the DCS network segment is a significant IT and OT coordination task — often the first barrier that blocks integration projects before any AI work begins.
DeltaV tag addressing uses module:parameter notation — opaque to the model
DeltaV tags follow Emerson's module:parameter convention — identifiers like FIC-101/PV.CV or TIC-204/SP.CV. These identifiers are meaningful inside the DCS but opaque when returned in a function result. Without a mapping layer that translates DeltaV addressing into descriptions a process engineer can interpret, the model receives data it can't present meaningfully in a response.
Raw historian time-series fills the context window and drives up token costs
DeltaV Continuous Historian logs process variables at high resolution. A function returning raw historian output for even a short time window sends thousands of timestamped records to the model. This consumes context budget rapidly, increases token costs, and degrades response quality — the model spends its attention on raw numerical data rather than on answering the question. Aggregation has to happen before the function responds.
DeltaV Continuous Historian is tightly integrated with DCS — access is restricted
The historian runs as part of DeltaV DCS infrastructure. Any new connection to it goes through Emerson's security model and typically requires DeltaV administrator involvement and a change management process. This is not a self-service integration — it involves the control system vendor and the site's DCS support team, adding lead time before any function calls can be tested.
Custom GPT Actions require a public OpenAPI spec with accurate schema
Custom GPTs retrieve data using Actions defined by an OpenAPI spec hosted at a public URL. Building a spec that accurately describes DeltaV tag discovery, current value retrieval, and aggregated historian queries — and keeping it maintained as the underlying bridge evolves — adds documentation overhead. Function schema quality also directly affects model reasoning quality, so a poorly structured spec produces unreliable agent behaviour.
What teams usually try
OPC-to-REST bridge on the OT network
Build a service on a DeltaV-accessible machine that reads historian data via OPC HDA, aggregates results, and exposes an HTTPS endpoint. Define the OpenAI function schema against this endpoint.
The catch: The service needs an outbound internet path from inside the OT network — a change on DCS infrastructure that DeltaV administrators and IT security have to approve. OPC DCOM is fragile across network boundaries. Maintaining the bridge adds ongoing infrastructure overhead.
Emerson DeltaV Cloud Connect or third-party bridge
Use Emerson's own cloud connectivity product or a third-party industrial data bridge to replicate DeltaV historian data to a cloud database. Point the function schema at the cloud endpoint.
The catch: Adds a vendor license and replication pipeline on top of the OpenAI integration. Replication introduces latency — the agent answers about replicated history, not live process values. Data residency may add compliance scope depending on the plant and process classification.
Export historian trend data to files, upload to Assistants
Export DeltaV historian data to CSV files and upload them as Assistants file attachments. The model reads file content to answer process questions.
The catch: The agent answers questions about the last export — not current process state. Manual export steps add operational burden. High-resolution historian data produces large files, and file retrieval in Assistants chunks across a large CSV poorly for time-range queries.
How TrendOps solves it
TrendOps Edge connects to DeltaV Continuous Historian on the OT network — reading via OPC, translating module:parameter addresses into readable context, and aggregating high-resolution history — then forwards structured data to TrendOps Platform in the cloud over a single outbound MQTT connection. Your OpenAI agent calls TrendOps Web API as a function endpoint or Custom GPT Action. No OPC from OpenAI's cloud, no inbound path to DCS infrastructure, no raw historian dumps filling the context window.
The function schema or OpenAPI spec points to TrendOps Web API — a cloud-accessible HTTPS endpoint. No OPC client, no DCOM, no inbound path to DeltaV infrastructure from OpenAI's servers.
TrendOps maps DeltaV module:parameter identifiers to human-readable descriptions. Function responses include context the model can use — not raw DCS addressing that means nothing outside the control room.
TrendOps aggregates historian data server-side. Function responses return interval summaries — not thousands of high-resolution records that exhaust the context window and drive up token costs.
TrendOps Edge reads DeltaV continuously. Function responses return current process values — not a snapshot from a replication pipeline with built-in latency.
TrendOps Edge pushes data out over a single outbound MQTT connection. No inbound path from OpenAI's cloud to DCS infrastructure. The agent's function calls never reach the DCS network.
TrendOps normalises DeltaV data alongside AVEVA PI, FactoryTalk, SQL, and MQTT sources. One function endpoint gives the agent a unified view — not a separate integration per historian.
What you end up with
No OPC client or DCOM on the cloud side — the agent calls a plain HTTPS endpoint.
Current process values — the agent knows what's happening right now.
DCS network stays closed — outbound MQTT only, no inbound path from OpenAI's cloud.
One endpoint, every OT source — not limited to DeltaV.
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 DeltaV process 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 OPC access to a DCS network to answer a question about process data
TrendOps gives your OpenAI agent a clean function endpoint for DeltaV Continuous Historian — translated, aggregated, and available without touching the DCS network.
Book a Demo