# AVEVA System Platform and Historian Private AI Layer Blueprint Generator

> Source: https://netray.co/tools/aveva-system-platform-historian-private-ai-blueprint-generator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Fill in your environment and get an architecture plan for a private AI assistant on AVEVA System Platform and Historian: components, security controls, rollout phases and open questions for IT.

## Category

mes-shop-floor

## Erp

AVEVA System Platform / Wonderware Historian

## Industry

Manufacturing, Aerospace and Defense

## Audience

- IT manager
- Controls engineer
- CIO
- Plant manager

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### Company name

**Key:** company

**Type:** text

**Default:** Acme Precision Ltd

#### System version

**Key:** version

**Type:** select

**Options:**

- System Platform 2017 / 2017 U3
- System Platform 2020 / 2020 R2
- System Platform 2023 / 2023 R2
- Older Wonderware (pre-2017)

**Default:** System Platform 2017 / 2017 U3

#### Database engine / data layout

**Key:** db

**Type:** select

**Options:**

- Historian on SQL Server (dedicated server)
- Historian on SQL Server (shared with Galaxy Repository)
- Historian reporting tier on SQL Server

**Default:** Historian on SQL Server (dedicated server)

#### Hosting

**Key:** hosting

**Type:** select

**Options:**

- On-prem server
- Private cloud
- Air-gapped

**Default:** On-prem server

#### Named users who will use the assistant

**Key:** users

**Type:** number

**Default:** 150

#### Sites or plants in scope

**Key:** sites

**Type:** text

**Default:** Plant 1 (pilot), Plant 2 (phase 3)

#### Main use cases

**Key:** usecases

**Type:** textarea

**Default:** Query tag history and alarm counts in plain language, locate the right tag by area and description, explain batch deviations using documents and trends, draft shift summaries.

#### Data that must never leave the site

**Key:** never_leave

**Type:** textarea

**Default:** Recipe parameters, tags from restricted areas, alarm text that reveals protected process details, any export-controlled program data.

#### GPU available

**Key:** gpu

**Type:** select

**Options:**

- No GPU yet (procure)
- 1 x 24 GB class
- 1 x 48 GB class
- 2 to 4 x 48 GB class
- 8 or more data center GPUs

**Default:** 1 x 48 GB class

#### Target go-live (phase 1)

**Key:** golive

**Type:** date

**Default:** 2027-02-01

**Blocks:**

#### Private AI Layer Architecture Plan: AVEVA System Platform and Historian

**Body:** Company: {{company}}
System: AVEVA System Platform and Historian ({{version}})
Data layout: {{db}}
Hosting: {{hosting}}
Sites in scope: {{sites}}
Named users: {{users}}
Target go-live for phase 1: {{golive}}

#### 1. Context and scope

**Body:** {{company}} runs AVEVA System Platform and Historian ({{version}}) and wants an AI assistant that works on the data and documents already held on site, without moving that data to a third-party cloud. Hosting model: {{hosting}}.

Main use cases:
{{usecases}}

Out of scope for the assistant: control writes of any kind, changes to controlled records without a person committing them, and any access beyond the roles each user already holds.

#### 2. Components

**Table:**

**Columns:**

- Component
- Design
- Notes for {{company}}

**Rows:**

**0:** Data access path

**1:** Read-only SQL login on the Historian Runtime database views via named, parameterised tools with time and row caps

**2:** Read-only identity, reviewed by IT and controls owners. Data layout: {{db}}.

**0:** Retrieval index

**1:** Tag catalog (name, description, unit, Galaxy area) plus SOPs, batch records and alarm philosophy documents

**2:** Rebuilt on a schedule; source permissions stored with each chunk.

**0:** Model serving

**1:** Open-weight model served with vLLM or Ollama on local GPUs

**2:** GPU available: {{gpu}}. Sized for {{users}} named users; see the sizing calculator.

**0:** Tool server

**1:** MCP or HTTP server exposing a small set of approved read operations with time and row caps

**2:** No free-form queries from the model. Every operation is parameterised and reviewed.

**0:** Identity and permissions

**1:** Galaxy areas and roles translated into per-role tag allow lists enforced in the tool server

**2:** Negative tests per role before each phase gate.

**0:** Audit

**1:** Append-only log of question, user, sources, tool calls, row counts and answer

**2:** Readable by security. Retention per site policy. Hosting: {{hosting}}.

#### 3. Security controls mapped to your inputs

**Table:**

**Columns:**

- Control
- How it is applied

**Rows:**

**0:** Data residency

**1:** Model, embeddings, index, tool server and logs all run on {{company}} infrastructure ({{hosting}}). No outbound calls for inference.

**0:** Data that must never leave the site

**1:** {{never_leave}}

**0:** Least privilege

**1:** Read-only service identity; per-role allow lists; no admin accounts for the assistant.

**0:** Write-back

**1:** No writes to runtime attributes. Drafts only; approved records go to CMMS or ERP through their APIs.

**0:** Air-gap readiness

**1:** Model weights and containers imported on approved media; embeddings run locally; no runtime internet dependency.

**0:** Monitoring

**1:** Alerts on unusual query volume, denied-access spikes and tool errors.

#### 4. Rollout in three phases

**Table:**

**Columns:**

- Phase
- Scope
- Exit criteria

**Rows:**

**0:** 1: Read-only questions (target {{golive}})

**1:** One area or line, read-only questions with sources shown, for a pilot group of the {{users}} users

**2:** Answer quality reviewed on a fixed question set; permission negative tests passed; audit log reviewed by security

**0:** 2: Drafts

**1:** Drafted shift summaries, deviation write-ups and reports that a person edits and owns

**2:** Edit rate and time saved measured; no unreviewed output enters a controlled record

**0:** 3: Approved actions

**1:** Records or requests created in downstream systems through supported APIs after human approval

**2:** Approval flow tested; rollback and audit proven; extension to further sites considered

#### 5. Open questions for IT

**Body:** 1. Is there a Historian reporting tier or replica, or would analytical queries land on the collecting server?
2. Which SQL Server edition and version hosts the Runtime database, and who is the DBA owner?
3. How are Galaxy areas and security roles defined, and can they be exported to build allow lists?
4. Is alarm logging to SQL enabled, and for how long is it retained?
5. Which tags use cryptic names, and who can supply descriptions for the in-scope set?
6. Who owns the model and index lifecycle (updates, re-indexing, evaluation) after go-live?
7. Which approval board signs off each phase gate?

#### Approvals

**Signatures:**

- IT / infrastructure
- Controls or OT owner
- Information security
- Business sponsor

**Notes:** This is a planning starting point, not a design guarantee. Confirm interfaces, versions and licensing against the vendor documentation for your installed release before committing to a build. Keep the assistant read-only against controlled records.

## Content

**Intro:** This generator turns your environment details into a structured architecture plan for adding a private AI assistant to AVEVA System Platform and Historian. It covers components, security controls, rollout phases and the questions your IT and controls teams need to answer, and it exports to PDF or Word.

**Sections:**

#### How to use the generator

**Body:** Fill in the company, version, data layout, hosting model, named users and sites. Write the main use cases in plain language and, just as important, list the data that must never leave the site. Choose the GPU capacity you have or expect. The output document updates as you type. Export it, circulate it to IT, controls and security, and use the open questions as the agenda for a first review meeting.

**Bullets:**

- Start with one area and one pilot group
- Write the never-leave list first
- Be honest about GPU availability
- Treat the output as a draft for review, not a final design

#### What the plan contains

**Body:** The plan has six parts: scope, a components table, security controls tied to your inputs, a three-phase rollout, open questions and an approvals block. The components table covers the six things every private AI layer needs: a data access path, a retrieval index, model serving, a tool server, identity and permissions, and audit. Each is stated in terms specific to AVEVA System Platform and Historian.

#### Design principles behind it

**Body:** The design follows a few principles. The assistant reads through approved, parameterised tools instead of free-form queries. It inherits the permissions each user already has. It never writes to control systems and writes to business systems only through supported APIs after a person approves the payload. Everything it does is logged. Inference runs on your own hardware, so the plan works in an air-gapped site as well as an on-prem one.

#### Common mistakes to avoid

**Body:** The usual failures are scoping too widely, giving the assistant an admin account for convenience, skipping negative permission tests, returning raw time-series or record dumps to the model instead of summaries, and ignoring data quality such as missing tag descriptions. Fix those in phase 1 and the later phases go much more smoothly.

**Cta:** If you want a second pair of eyes on this plan for your environment, Netray designs and builds private AI layers for on-prem industrial and ERP systems, and can review the document with your team.

**Faq:**

#### Does this work for an air-gapped site?

**Answer:** Yes. Choose Air-gapped as the hosting option. The design uses local models, a local index and a local audit log, with software imported on approved media and no runtime internet dependency.

#### Is the generated document a final design?

**Answer:** No. It is a structured starting point for review. Confirm interfaces, versions and licensing with the vendor documentation for your release, and adjust the components to what your IT team approves.

#### Which model should we use?

**Answer:** The plan assumes an open-weight model served with vLLM or Ollama. Which one fits depends on GPU memory, language needs and evaluation on your own question set, so test two or three candidates in phase 1.

#### Can the assistant change data in the system?

**Answer:** Not directly. The plan restricts it to read access, with write-back limited to supported APIs in business systems after a person approves each payload. Control-system writes are out of scope.

## Search terms

add AI to AVEVA System Platform and Historian on-prem, System Platform AI architecture, System Platform private AI blueprint, System Platform local LLM, air-gapped AI System Platform, on-prem AI architecture document template, private AI reference architecture manufacturing, System Platform AI security controls

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