AdvancedAVEVA System Platform / Wonderware HistorianHistorian (Runtime database) / Galaxy Repository / Alarm DB

AI on AVEVA System Platform and Wonderware Historian, Fully On-Prem

Question
how to add AI to AVEVA System Platform and Wonderware Historian on-prem

Also searched as

  • Wonderware Historian AI integration without cloud
  • query AVEVA Historian with a local LLM
  • System Platform galaxy data for AI assistant
  • chat with Wonderware historian SQL data

Short answer

AVEVA Historian stores its data in Microsoft SQL Server and exposes history through the Runtime database views, so a read-only SQL account behind a tool server is the simplest safe path. Index the Galaxy object model and plant documents, serve an open-weight model on local GPUs, and enforce area-based access in the tool layer.

Applies to: AVEVA Historian (Wonderware Historian) 2017 and later on SQL Server, System Platform 2017 and later. Older Wonderware versions use the same concepts with different retrieval details.

Reference build, in order

  1. 1Create a dedicated read-only SQL login (or Windows group) on the Historian SQL Server with access limited to the Runtime database views you need.
  2. 2Prefer a reporting copy: run analytical queries against a replica or a separate Historian tier, not the server collecting from the plant.
  3. 3Export the tag list with descriptions, engineering units and the Galaxy area each tag belongs to, and use it as the retrieval catalog.
  4. 4Index plant documents (SOPs, batch records, alarm philosophy, maintenance notes) with their source permissions.
  5. 5Build a tool server that wraps parameterised history queries with a time cap and a row cap, and returns summaries.
  6. 6Serve an open-weight model with vLLM or Ollama on local GPUs, connected only to that tool server.
  7. 7Map each user to a set of allowed areas and tag groups, enforce it in the tool server, and log every call.
  8. 8Start read-only, then add drafted reports, then approved actions in downstream systems such as your CMMS or ERP.

Data access paths and the objects that matter

AVEVA Historian runs on SQL Server. The Runtime database holds tag definitions (the Tag view and typed views such as analog and discrete tag definitions) and exposes retrieval through the History view, where you control the result with the wwRetrievalMode and related ww parameters in the WHERE clause. The Live view returns the current value. Because it is ordinary T-SQL, a read-only SQL login is enough for an AI tool server.

The Galaxy Repository is also a SQL Server database, but it holds the engineering model (templates, instances, areas, attributes). Treat it as read-only reference data and use the supported GRAccess toolkit if you ever need to change configuration; do not write to it directly. Alarm and event records can be stored in a separate alarm database when alarm logging to SQL is enabled.

Always bound a query. Ask for cyclic or average retrieval at a sensible resolution over a limited window, never an unbounded delta pull of a fast tag.

-- Hourly average for one tag over the last 24 hours (read-only)
SELECT DateTime, TagName, Value, QualityDetail
FROM Runtime.dbo.History
WHERE TagName = 'Reactor1.Temp'
  AND wwRetrievalMode = 'Cyclic'
  AND wwResolution = 3600000
  AND DateTime >= DATEADD(hh, -24, GETDATE())
  AND DateTime <= GETDATE();

-- Current value
SELECT TagName, DateTime, Value FROM Runtime.dbo.Live WHERE TagName = 'Reactor1.Temp';

Reference architecture

Place the tool server, retrieval index and model server in the same zone as the Historian reporting tier, and let only the tool server reach SQL Server. The tool server should expose a handful of named operations (current value, trend summary, min and max in window, list tags in area, alarm counts) and never a free-form SQL passthrough.

The retrieval index combines the tag catalog (name, description, unit, area) with documents. Questions such as 'what was the feed temperature during last Thursday's off-spec batch' need both: documents to find the batch and tags to read the history.

In an air-gapped plant, bring models and containers in on approved media, run embeddings locally, and keep logs on the isolated network. There is no outbound dependency.

Permissions: areas, roles and what SQL can and cannot enforce

System Platform security is built around users, roles, areas and security classifications on attributes. The Historian's SQL layer, by contrast, mostly gives you object-level SQL permissions, not per-tag row security. If you give an AI service a SQL login, it can read every tag that login can see.

So enforce the boundary in the tool server. Build an allow list per role from the Galaxy area structure (for example, packaging operators see packaging areas only), apply it to the tag catalog used for retrieval, and reject any tool call outside it. Keep the mapping in a version-controlled file that your controls team reviews.

Verify with negative tests: a user outside the area should not get values, tag names, or even hints that the tag exists.

Write-back, sizing and phases

Do not write to runtime attributes from an AI service. System Platform attribute writes can affect running equipment, and security classifications exist for good reasons. Useful write-backs happen in business systems: a draft downtime record, a maintenance request in your CMMS, a quality hold in your ERP, each through that system's supported API with a person approving the payload.

For sizing, expect one 24 to 48 GB GPU to carry a department of tens of occasional users, and two to four GPUs for a few hundred active users with long contexts. The index for tens of thousands of documents is typically a few GB to low tens of GB. Historian data itself is queried live and is not copied into the index.

Phase 1 is read-only trend and alarm questions for one area. Phase 2 adds drafted shift summaries and batch deviation write-ups. Phase 3 adds approved tickets and records in downstream systems.

Limits and honest alternatives

If your people mainly need trends, the Historian Client tools and your existing dashboards are fine, and an assistant adds little. The value shows up when someone must connect history to documents, batches and work orders, or when staff do not know which tag to look at.

Version matters: retrieval options, view columns and alarm storage differ across Historian generations, so validate every query against your build. Tag naming conventions that encode meaning in cryptic strings need a metadata pass first. AVEVA's own cloud services are an option where policy permits; this design is for sites that cannot use them.

Try it here, free

AVEVA System Platform and Historian AI Assistant Sizing and Value Calculator

Open full tool

Estimate peak concurrency, GPU count, index size, hours saved and payback for a private on-prem AI assistant on AVEVA System Platform and Historian.

Common pitfalls

  • !Giving the assistant a SQL login with access to the whole Runtime database and assuming area security still applies.
  • !Passing free-form SQL from the model to the Historian. Use named, parameterised operations with caps instead.
  • !Running analytical pulls on the production Historian that is collecting from the plant.
  • !Asking for unbounded delta retrieval on a fast tag and returning the result to the model.
  • !Writing to Galaxy or runtime attributes from automation built for chat.
  • !Ignoring the tag quality column, so bad-quality samples get averaged into answers.

How an ERP-grounded AI assistant handles this

Netray builds the tool server, the area-aware access layer and the document retrieval on your hardware, then connects it to ERP data through ERPray so questions can span history, work orders and quality records. Every tool call is visible to the user.

See ERPray

Frequently asked questions

Can the assistant query the Historian with SQL it writes itself?

It can, but it should not. Free-form SQL from a model is hard to bound and audit. Wrap the few queries you trust as named tools with parameters, a time cap and a row cap, and let the model choose among them.

Does it work with older Wonderware versions?

The pattern does, since history is still SQL-readable, but column names, retrieval options and alarm storage differ by version. Test each query against your exact build and plan a metadata cleanup.

How do we keep operators from seeing other areas?

Derive allowed areas from your System Platform roles and apply them in the tool server and the retrieval index. SQL alone will not do per-tag restriction, so this enforcement layer is mandatory.

Is any data sent outside the plant?

Not in this design. The model, embeddings, index, tool server and audit log all run on your servers, and the air-gapped variant has no outbound connection at all.

Related

How-to

How to integrate Ignition with your ERP

Do not let Ignition write straight into ERP tables. Put a staging layer between them: Ignition writes production events to a staging table or calls an ERP API through a gateway script, and a controlled poster validates and posts them to the ERP. Pull work orders the other way with a scheduled gateway script or Named Query against a read-only view or API.

How-to

How to Calculate OEE from MES Data and ERP Standards

OEE equals Availability times Performance times Quality. Availability comes from MES run and stop events against planned production time, Performance compares actual output to the ideal cycle time (usually the routing standard from the ERP), and Quality is good units divided by total units. The numbers are only trustworthy if planned time, ideal cycle time and the good/scrap split are defined once and used consistently.

Advanced

How to Add AI to the AVEVA PI System On-Prem, Without Moving Data to a Cloud

Put a read-only tool server in front of PI Web API, index the PI AF asset model plus your SOPs and shift logs, and serve an open-weight model on local GPUs. The model asks tools for bounded summaries instead of raw tag data, and every call runs with the asking user's PI identity and is logged.

Advanced

How to add a private AI layer to Infor LX / BPCS on-prem

BPCS and Infor LX run on IBM i with their data in Db2 for i, in files that carry short coded names by module. A private AI layer reads those files through read-only SQL views over a replica, indexes documents and attachments separately, exposes approved queries through a tool server, and serves an open-weight model on local GPUs. Writes, if any, go through the supported transaction programs with human approval.

Advanced

How to add a private AI layer to Infor System21 on-prem

System21 runs on IBM i with its business data in Db2 for i. The practical private AI pattern is a read-only replica or extract, SQL views that give files readable names, a retrieval index over documents, a tool server of approved queries, and a locally served open-weight model. User visibility is carried over from System21 security and company set-up, and writes only go through its supported entry points after approval.

Advanced

How to add a private AI layer to Infor EAM on-prem

On-prem Infor EAM stores its data in an Oracle or SQL Server schema whose tables use the R5 prefix, and it exposes web services for supported access. A private AI layer reads equipment, work order and parts data through read-only views on a reporting copy, indexes failure notes and manuals for retrieval, mirrors EAM organisation security, and serves an open-weight model locally. Work orders created or changed by the assistant go through EAM's web services after a person approves.

AI for ERP

AI for SAP Plant Maintenance: Notifications, Work Orders, and Predictive Signals

AI grounded on SAP PM data that triages notifications, drafts work orders, standardizes failure codes, and flags predictive maintenance signals, on-prem.

AI for ERP

AI for Plex Manufacturing Cloud, Grounded in Your Production Data

Put AI on Plex production, quality, and genealogy data without a public model. On-prem or private-cloud LLMs, RAG, and agents built for Plex shops.

Stuck on AVEVA System Platform / Wonderware Historian?

Talk to engineers who work inside AVEVA System Platform / Wonderware Historian every week, and who build private AI that answers these questions from your own ERP data.

Talk to an ERP engineerBrowse ERP Help
All ERP Help articles

Keep exploring

Free tools

ERP fixes and how-tos

AI on your ERP

Integrations

Software