# How to connect an on-prem AI assistant to Kepware and OPC UA servers

> Source: https://netray.co/erp-help/private-ai-layer-kepware-opc-ua-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

OPC UA gives you live values, not history, so the private AI layer needs a read-only OPC UA client with a node whitelist plus a time-series store for trends. Kepware can feed that store through its own logging or gateway agents. A local open-weight model calls approved tools and never writes to a device tag.

## Kind

advanced

## System

mfg-systems

## Erp

Kepware and OPC UA servers

## Module

KEPServerEX / OPC UA

## Query

how to connect an LLM to Kepware OPC UA on-prem

## Alternate Queries

- Kepware AI integration without cloud
- OPC UA server AI assistant on-prem
- read Kepware tags with Python for AI
- KEPServerEX IoT Gateway REST for LLM

## Applies To

KEPServerEX / ThingWorx Kepware Server 6.x and newer, any standards-based OPC UA server. Plug-in names and defaults vary by version.

## Steps

### How to wire a private AI layer to Kepware

**Items:**

Map your channels, devices and tags in the Kepware project, and decide which of them the assistant may ever read. Write the list down as an allowlist by node id.

Create a dedicated OPC UA endpoint user or certificate for the AI layer. In the OPC UA server settings use a signed and encrypted security policy and trust only that client certificate.

Set the tag access for the AI layer to read only. Tags that are read/write for HMI or MES use should be reached through a different identity, not the AI client.

Decide where history lives. OPC UA servers typically serve current values, so send selected tags to a historian or time-series database using Kepware's logging plug-in, MQTT or REST gateway agents, or an existing historian.

Build a tool server that reads current values from the whitelisted nodes and queries the history store for trends and aggregates. Return units, quality and timestamps with every value.

Index device documentation and tag descriptions so the model can explain what a tag means, not only what it reads.

Serve an open-weight model locally with vLLM or Ollama and restrict it to the tool server. Log node ids read, query ranges and the user who asked.

Test with deliberately bad inputs: unknown tags, stale quality, a device offline. The assistant must say so rather than guess.

## Sections

### Data access paths: OPC UA, the Configuration API and gateway agents

**Body:**

Kepware exposes tag data over OPC UA, with nodes addressed by namespace and a string identifier that follows the channel, device and tag hierarchy. Any compliant OPC UA client library can browse and read them. Kepware also ships a REST-based Configuration API for reading and managing the project itself, and the IoT Gateway with REST server, MQTT and REST client agents that publish selected tags outward.

For an AI layer, use the Configuration API only to read project structure and tag descriptions into your retrieval index. Use OPC UA reads for current values. Do not enable write-capable agents for the assistant's identity. Check the default ports and endpoints in your installation and firewall them so only the AI host can reach them.

Remember that Kepware is a driver layer. The values come from PLCs and devices over drivers such as Modbus, EtherNet/IP or Siemens protocols, and poll rates you set in Kepware translate into load on those devices. An AI client that reads many tags often can disturb a slow controller.

**Code:**

# Read-only OPC UA client sketch (Python asyncua). Node ids follow your project.
import asyncio
from asyncua import Client

ALLOWED = {"ns=2;s=Line1.Press1.Temp", "ns=2;s=Line1.Press1.Cycles"}

async def read_nodes(url, node_ids):
    async with Client(url=url) as client:
        out = {}
        for nid in node_ids:
            if nid not in ALLOWED:
                raise PermissionError(nid)
            dv = await client.get_node(nid).read_data_value()
            out[nid] = (dv.Value.Value, dv.StatusCode.name, dv.SourceTimestamp)
        return out

### Reference architecture and the history problem

**Body:**

The architecture has five parts: a read-only OPC UA client, a time-series store, a retrieval index over documentation, a tool server and a local model. If you already run a historian, use it. If not, a database fed by Kepware's logging plug-in or by an MQTT broker is enough for trends. Without a store the assistant can only report what a tag reads right now.

Run the model with vLLM or Ollama on local GPUs and give it tools such as read_current, trend_summary and compare_periods. Aggregate in the tool: min, max, average, count of out-of-range samples, time in state. The model then explains numbers rather than receiving thousands of raw samples.

In an air-gapped site, the OPC UA client, store, index, model and logs all live inside the enclave. Move model files and updates in on approved media. Keep time sources consistent, because timestamp drift across devices produces confusing answers.

### Permissions, write-back and what will not work

**Body:**

OPC UA security is the first permission layer. Use signed and encrypted sessions, certificate trust lists and a username or certificate dedicated to the AI client, with read-only rights on only the nodes you allow. The second layer is in your tool server: map each user to areas and lines, and refuse reads outside that scope.

Do not allow the assistant to write tags. Writing to a controller through a language model is a safety and quality risk that no approval screen fully removes. If an action is needed, have the assistant draft a work order or change request in a supporting system, where a human acts on it through normal procedures.

Limits: OPC UA data has no business context by itself. A tag called Temp1 means nothing without the asset description, so invest in the tag dictionary. Slow drivers, poor tag naming and unreliable quality flags will limit answer quality more than the model will. For simple dashboards, your SCADA or historian trending is the better tool.

### Sizing and phased rollout

**Body:**

Tag volume drives the history store, not the model. A few thousand tags at one-second to ten-second resolution is routine for a time-series database on a single server; plan storage from tag count, rate and retention. The model side is sized by users and questions per day, usually one to two GPUs for a plant-level assistant.

Phase 1: current values and short trends on one cell, read-only, with the node id and timestamp shown in every answer. Phase 2: shift and downtime summaries drafted from history. Phase 3: approved actions such as creating a maintenance request through a supported API in another system, never writing to the device layer.

## Pitfalls

- Reading hundreds of tags at one-second intervals from a slow PLC driver and degrading the control system's own communication.
- Using the same OPC UA identity for HMI, MES and AI, which makes least privilege impossible.
- Enabling security policy None for convenience and leaving it on in production.
- Skipping the quality code, so the assistant reports stale or bad values as if they were good.
- Assuming OPC UA stores history. Without a store the assistant cannot answer trend questions.
- Giving the model a write tool because a demo needed one.

## Ai Angle

DataRay can connect to a time-series store or database fed from Kepware and answer questions with the query shown. For OPC UA specifics, Netray builds the read-only client, node allowlist and tool server and serves the model on your own GPUs, so live-value questions and trend questions work without opening the control network to the cloud.

## Faq

### Can an LLM read Kepware tags directly?

**Answer:** Not directly, and it should not. A tool server holds a read-only OPC UA client with a node allowlist. The model asks the tool for a value, the tool reads it and returns value, quality and timestamp, and the model explains the result.

### Where does historical data come from?

**Answer:** From a historian or time-series database. OPC UA servers generally serve current values. Kepware can log or forward selected tags to a store, and the assistant queries that store for trends and aggregates.

### Is the Configuration API useful for AI?

**Answer:** Yes for reading project structure, channels, devices and tag descriptions into a retrieval index, so the assistant can explain tags. Use a read-only account and keep write operations away from the AI identity.

### Should the assistant ever write to a PLC tag?

**Answer:** No. Route any needed action to a human through a work order or change request. A language model writing to a controller is an avoidable safety and quality risk.

### What if our OPC UA server is not Kepware?

**Answer:** The pattern is the same for any standards-compliant OPC UA server: allowlisted nodes, signed and encrypted sessions, read-only rights, a history store and a tool server in front of the model.

## Search terms

Kepware AI integration, OPC UA AI assistant, KEPServerEX LLM, connect LLM to OPC UA, Kepware IoT Gateway REST, on-prem AI shop floor data, read only OPC UA client, air-gapped OPC UA AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json