# AI on AVEVA System Platform and Wonderware Historian, Fully On-Prem > Source: https://netray.co/erp-help/private-ai-layer-aveva-system-platform-historian-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind advanced ## System on-prem-apps ## Erp AVEVA System Platform / Wonderware Historian ## Module Historian (Runtime database) / Galaxy Repository / Alarm DB ## Query how to add AI to AVEVA System Platform and Wonderware Historian on-prem ## Alternate Queries - 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 ## 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. ## Steps ### Reference build, in order **Items:** - Create a dedicated read-only SQL login (or Windows group) on the Historian SQL Server with access limited to the Runtime database views you need. - Prefer a reporting copy: run analytical queries against a replica or a separate Historian tier, not the server collecting from the plant. - Export the tag list with descriptions, engineering units and the Galaxy area each tag belongs to, and use it as the retrieval catalog. - Index plant documents (SOPs, batch records, alarm philosophy, maintenance notes) with their source permissions. - Build a tool server that wraps parameterised history queries with a time cap and a row cap, and returns summaries. - Serve an open-weight model with vLLM or Ollama on local GPUs, connected only to that tool server. - Map each user to a set of allowed areas and tag groups, enforce it in the tool server, and log every call. - Start read-only, then add drafted reports, then approved actions in downstream systems such as your CMMS or ERP. ## Sections ### Data access paths and the objects that matter **Body:** 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. **Code:** -- 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 **Body:** 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 **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Can the assistant query the Historian with SQL it writes itself? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms AI for Wonderware Historian, AVEVA Historian AI integration, System Platform AI on-prem, chat with Wonderware historian, Runtime.dbo.History query, local LLM for SCADA historian, air-gapped AI AVEVA, Galaxy Repository AI, MCP server historian, private AI for MES data --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json