# How to Add AI to a Self-Hosted Ignition Gateway Without Cloud

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

## Short answer

Ignition writes history and alarms to a SQL database you own, so a read-only database account plus a few WebDev or Named Query endpoints give an AI tool server clean access. Index the tag tree and your plant documents, serve an open-weight model on local GPUs, and map Ignition roles and tag permissions into the tool layer.

## Kind

advanced

## System

mfg-systems

## Erp

Ignition by Inductive Automation (self-hosted)

## Module

Gateway / Tag Historian / Alarm Journal / WebDev

## Query

how to add AI to Ignition SCADA on-prem

## Alternate Queries

- Ignition Tag Historian AI integration
- query Ignition historian tables with a local LLM
- Ignition WebDev endpoint for AI assistant
- Ignition Perspective AI without cloud

## Applies To

Ignition 8.1 and 8.3 self-hosted Gateway with the Tag Historian and Alarm Journal writing to MySQL, MariaDB, PostgreSQL or SQL Server. Module availability varies by license.

## Steps

### Reference build, in order

**Items:**

- Create a read-only database user on the historian and alarm journal database. Prefer a read replica where your DBA can provide one.
- Export the tag tree (paths, descriptions, units, tag groups) and use it as the retrieval catalog.
- Expose a few approved read endpoints, either as WebDev resources on the Gateway or as Named Queries called by a separate service, each with fixed parameters and caps.
- Index plant documents (SOPs, downtime reason guides, maintenance notes) with source permissions.
- Serve an open-weight model with vLLM or Ollama on local GPUs and connect it only to the tool server.
- Map Ignition roles, security zones and tag permissions into allow lists in the tool server.
- Log every question, tool call and row count.
- Roll out read-only, then drafted outputs, then approved writes to database tables that your own screens already use, never to PLC tags.

## Sections

### What Ignition gives you to read

**Body:**

With the Tag Historian module, history lands in SQL tables you control. By default, tag definitions go to a table of tag entries (sqlth_te) and values go to monthly partition tables named like sqlt_data_1_2026_10, with columns for tagid, value columns by type (intvalue, floatvalue, stringvalue, datevalue), data integrity and a t_stamp in epoch milliseconds. A partitions table records which monthly tables exist. Alarm Journal data lands in alarm_events and alarm_event_data when you enable a database journal.

Inside the Gateway you also have scripting (system.tag.queryTagHistory, system.db.runNamedQuery), Named Queries, and the WebDev module for custom REST-style endpoints. For an AI service the best pattern is a small set of Named Queries and WebDev handlers, because you control parameters, caps and permissions in one place and they are easy to review.

Ignition's scripting is Jython-based, so keep handlers short and push heavy aggregation into SQL.

**Code:**

-- Last 24 hours for one tag from the monthly partition (read-only)
SELECT te.tagpath, d.t_stamp, d.floatvalue, d.dataintegrity
FROM sqlth_te te
JOIN sqlt_data_1_2026_10 d ON d.tagid = te.id
WHERE te.tagpath = 'line1/press01/temperature'
  AND d.t_stamp >= 1792454400000
ORDER BY d.t_stamp DESC
LIMIT 500;

-- Alarm journal, last 24 hours
SELECT eventtime, eventtype, source, displaypath, priority
FROM alarm_events
WHERE eventtime >= NOW() - INTERVAL 1 DAY;

### Reference architecture

**Body:**

Keep the model server, tool server and retrieval index on a server separate from the Gateway so a heavy question cannot starve your SCADA. The tool server reaches the historian database through the read-only account, and optionally the Gateway's WebDev endpoints with an API token or service identity.

Because queries span monthly partitions, put partition handling in the tool server: given a time range, it picks the right tables from the partitions table and never asks the model to name a table. Return aggregates (average, min, max, count, time above limit), not raw rows.

In an air-gapped site, this works unchanged: Ignition is self-hosted, the database is local, and models and containers are brought in on approved media.

### Permissions: roles, zones and tag security

**Body:**

Ignition authenticates through user sources and identity providers, assigns roles, and controls access with security zones and tag or project permissions. The database underneath knows none of that, so a SQL account sees every tag.

Mirror the Gateway model: for each AI user, resolve roles from the same identity provider, translate them to allowed tag folders and screens, and filter both tool results and retrieved catalog entries. A WebDev endpoint can read the caller's roles itself, which keeps the rule in one place.

Run negative tests with a restricted role and confirm out-of-scope tags cannot be found by name, description or aggregate.

### Write-back, sizing and phases

**Body:**

Ignition can write to PLC tags, and an AI service must not. Safe, useful writes go to business tables or systems: a downtime reason entered in the same table your Perspective screen writes, a maintenance request, a quality note. Use a Named Query or WebDev handler with validation, and show the person the exact record before it is saved.

As a range, one 24 to 48 GB GPU supports tens of occasional users; hundreds of active users usually need two to four GPUs. A document index in the tens of thousands of files fits in a few GB to low tens of GB. Historian data stays in your database and is queried live.

Phase 1: read-only history and alarm questions for one area. Phase 2: drafted shift summaries and downtime analysis. Phase 3: approved entries into your downtime and maintenance workflows.

### Limits and when Ignition alone is enough

**Body:**

If the need is dashboards, alarm pages and reports, Ignition's own Perspective, Vision and Reporting tools do that well without an AI layer. The assistant adds value for ad-hoc questions across history, alarms and documents, and for people who do not know the tag tree.

Be careful with history table sizes and pruning: very large partitions need good indexes, or the DBA will push back. Tag path conventions matter; flat, cryptic names give poor retrieval. Ignition-based MES builds often store business data in custom tables that you must document before the assistant can use them.

## Pitfalls

- Letting the model name historian tables. Resolve monthly partitions in code from the partitions table.
- Giving the AI account write access to the historian database.
- Running analytical queries against the same database instance that the Gateway is logging to under load.
- Assuming database access respects Ignition roles and security zones. It does not.
- Allowing any path from the AI service to PLC tag writes.
- Returning thousands of raw samples to the model instead of aggregates.

## Ai Angle

Netray builds the tool server, partition-aware queries and role mapping on your hardware, then links Ignition data to ERP records through ERPray, so downtime on a work centre can be tied to the work order, the part and the customer, with every query visible to the user.

## Faq

### Do we need the WebDev module?

**Answer:** No. A tool server with a read-only database account and the right queries works without it. WebDev is convenient when you want Gateway role checks applied inside Ignition itself.

### Does this work with Ignition Cloud Edition or Edge?

**Answer:** This page targets a self-hosted Gateway with a local database. Other editions may have different logging options, so check where history and alarms actually land before applying the pattern.

### Can the AI write a downtime reason?

**Answer:** Yes, if it writes to the same table your screens use, through a validated handler, and a person approves the exact record first. It should never write to PLC tags.

### Will queries slow down our SCADA?

**Answer:** They can if they hit the live logging database. Use a replica or a separate reporting instance, cap time ranges and rows, and return aggregates so queries stay cheap.

## Search terms

AI for Ignition SCADA, Ignition Tag Historian AI, sqlth_te query, Ignition WebDev AI endpoint, Ignition Named Query, local LLM Ignition, air-gapped Ignition AI, Ignition alarm journal analysis, MCP server Ignition, private AI SCADA on-prem

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