AdvancedIgnition by Inductive Automation (self-hosted)Gateway / Tag Historian / Alarm Journal / WebDev

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

Question
how to add AI to Ignition SCADA on-prem

Also searched as

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

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.

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.

Reference build, in order

  1. 1Create a read-only database user on the historian and alarm journal database. Prefer a read replica where your DBA can provide one.
  2. 2Export the tag tree (paths, descriptions, units, tag groups) and use it as the retrieval catalog.
  3. 3Expose 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.
  4. 4Index plant documents (SOPs, downtime reason guides, maintenance notes) with source permissions.
  5. 5Serve an open-weight model with vLLM or Ollama on local GPUs and connect it only to the tool server.
  6. 6Map Ignition roles, security zones and tag permissions into allow lists in the tool server.
  7. 7Log every question, tool call and row count.
  8. 8Roll out read-only, then drafted outputs, then approved writes to database tables that your own screens already use, never to PLC tags.

What Ignition gives you to read

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.

-- 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

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

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

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

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.

Try it here, free

Ignition SCADA 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 Ignition SCADA.

Common 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.

How an ERP-grounded AI assistant handles this

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.

See ERPray

Frequently asked questions

Do we need the WebDev module?

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?

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?

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?

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.

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.

Advanced

How to Connect OPC UA Machine Data to Your ERP

Do not connect OPC UA servers straight to the ERP. Read machine tags through an edge gateway or MES, convert signals into business events (cycle complete, stop, state change, count), attach the work order context, and post summarised confirmations to the ERP through its supported API. The ERP wants quantities, times and reasons per order, not millions of raw tag values.

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

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

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.

How-to

How to Send Production and Labor Reporting from MES to ERP

Treat the ERP work order as the system of record for cost and quantity, and the MES as the system of record for what physically happened. Send one confirmation message per operation (or per shift or lot) containing work order, operation sequence, good quantity, scrap quantity with reason, and labor start/stop per employee and work center, post it through the ERP's supported transaction API, and make the message idempotent so a retry never double-posts.

Advanced

ISA-95 and B2MML: How to Integrate ERP with MES

ISA-95 defines the boundary between business systems (Level 4, the ERP) and manufacturing operations (Level 3, the MES) and the information that crosses it. B2MML is the XML implementation of those models. In practice you exchange a ProductionSchedule from ERP to MES, and ProductionPerformance, plus material and equipment information, back, mapping each element to your ERP's work order and confirmation APIs.

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 Ignition by Inductive Automation (self-hosted)?

Talk to engineers who work inside Ignition by Inductive Automation (self-hosted) 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