AdvancedPlant SCADA alarm and event logsSCADA alarm journal / event history

How to use AI on SCADA alarm and event logs without leaving the site

Question
how to use AI on SCADA alarm logs on-prem

Also searched as

  • AI alarm rationalization SCADA
  • LLM analysis of SCADA event log without cloud
  • alarm flood analysis with AI
  • ISA-18.2 alarm KPIs from SCADA database

Short answer

Alarm and event logs are structured, high volume and sensitive, which makes them a good fit for a local AI layer. Export or replicate the journal to a reporting store, compute ISA-18.2 style KPIs with queries, and let a local model explain patterns and draft rationalization notes. The assistant is advisory and never acknowledges, shelves or changes alarms.

Applies to: Any SCADA or HMI platform that keeps alarm history in a database or exportable files, such as Ignition, WinCC, FactoryTalk or Wonderware-class systems. Table and export names differ by product.

Rollout for an alarm and event AI layer

  1. 1Identify where alarm history lives: a SQL journal, a historian event table, CSV or syslog exports. Note retention and time zone handling.
  2. 2Replicate or export the journal to a reporting database on the supervised network so analysis never touches the live SCADA database.
  3. 3Normalise columns into one schema: timestamp, source tag or area, alarm name, priority, state transition (active, acknowledged, cleared), operator or station, and message text.
  4. 4Compute baseline KPIs in SQL: alarms per operator per 10 minutes, peak 10-minute count, top 10 most frequent alarms, standing alarms, chattering alarms and time to acknowledge.
  5. 5Index the alarm philosophy, the alarm rationalization master list, response procedures and past incident reviews for retrieval, tagged by area.
  6. 6Expose approved read tools: top_alarms, flood_events, chattering_alarms, alarm_history, plus search over the philosophy and procedures.
  7. 7Serve an open-weight model locally and restrict it to those tools. Output explanations, candidate causes and draft rationalization entries for the alarm management team to review.
  8. 8Keep human ownership: changes to limits, priorities or suppression go through your management-of-change process.

Data access paths and what the logs contain

Many SCADA platforms write alarm and event history to a relational database. Ignition's alarm journal, for example, uses SQL tables for alarm events and event data; other products use their own databases, historian event stores or exportable files. Because names differ widely, build a small adapter per platform that maps the vendor format into one reporting schema.

Event logs often mix alarms, operator actions, mode changes and system messages. Keep the event type and operator station fields; they matter for analysis of what operators did after an alarm. Watch time zones and daylight saving: a one-hour shift produces false flood windows.

Query the reporting copy, not the live journal. The aim is to answer questions such as which five alarms generated most of last month's volume, and what happened in the 30 minutes before a trip.

-- Alarm rate per 10-minute window on the reporting copy (illustrative schema)
SELECT DATEADD(minute, (DATEDIFF(minute, 0, event_time) / 10) * 10, 0) AS window_start,
       COUNT(*) AS alarm_count
FROM rpt.alarm_events
WHERE state = 'ACTIVE'
  AND area = 'Reactor Unit 2'
  AND event_time >= DATEADD(day, -30, GETDATE())
GROUP BY DATEADD(minute, (DATEDIFF(minute, 0, event_time) / 10) * 10, 0)
HAVING COUNT(*) >= 10
ORDER BY alarm_count DESC;

Reference architecture and KPIs

Components: reporting database, KPI queries, retrieval index over philosophy and procedures, tool server, local model and audit log. Do the arithmetic in SQL. The model is for explanation and drafting: summarising a flood, grouping related alarms, suggesting which ones look like candidates for rationalization, and citing the relevant procedure.

ISA-18.2 and IEC 62682 describe an alarm management lifecycle, and the EEMUA 191 guidance is often cited for operator workload benchmarks such as the number of alarms per operator per 10 minutes. Use the thresholds your own philosophy document sets. The assistant should read them from that document rather than from the model's memory.

For an air-gapped plant the whole stack runs inside the enclave. Provide model files and updates through your controlled media process and keep logs local.

Permissions, write-back and what the assistant must never do

Restrict users by area, matching the SCADA's own area security or your site roles. Engineers and alarm management teams usually need more than operators, and an operator-facing view may be limited to explanation of the alarms on their consoles.

The assistant must not acknowledge, shelve, suppress or reconfigure alarms, and it must not be part of any safety function. Alarm changes belong to a controlled process, with the assistant at most producing a draft change request for the alarm management team. Treat the platform under IEC 62443-style zone and conduit thinking: read-only data flow outward, no control path inward.

Limits: poor tag naming, missing priorities and short retention cap the value. Real-time guidance during an upset is a different problem with different risk, and a language model should not be placed in the operator's decision loop without extensive assurance work. Start with after-the-fact analysis.

Sizing and phased rollout

Alarm data is smaller than raw process history; a busy site might log hundreds of thousands to millions of events per month, which a modest SQL server handles. The model side again depends on users and questions, often one GPU for an engineering group.

Phase 1: monthly KPI reports and read-only questions about top alarms and floods. Phase 2: drafted rationalization entries and incident summaries. Phase 3: draft change requests routed into your management-of-change tool with approval. Compare the assistant's findings with your alarm management team's own analysis before trusting it.

Try it here, free

SCADA Alarm and Event Log AI Assistant Sizing and Value Calculator

Open full tool

Estimate GPUs, index size, hours saved and payback for a private AI assistant over SCADA Alarm and Event Log.

Common pitfalls

  • !Analysing the live journal and slowing the SCADA database during a process upset.
  • !Mixing time zones or ignoring daylight saving, which creates false flood windows.
  • !Letting the model compute KPIs from pasted text instead of SQL.
  • !Giving the assistant any acknowledge, shelve or suppress capability.
  • !Ignoring operator actions in the event log, so analysis explains alarms but not responses.
  • !Treating after-the-fact analysis as proof the model is ready for real-time operator support.

How an ERP-grounded AI assistant handles this

DataRay can sit over the reporting database and show the SQL for every KPI and answer. Netray can also build the adapter from your SCADA's journal format, the retrieval index over your alarm philosophy and the local model serving, keeping the stack read-only and inside your network.

See ERPray

Frequently asked questions

Can AI do alarm rationalization?

It can speed up the preparation: grouping related alarms, finding chattering and stale ones, drafting entries against your philosophy. Decisions on limits, priorities and consequences belong to the multidisciplinary team and your management-of-change process.

Does the assistant need access to the live SCADA?

No. Use a replicated or exported journal on the reporting side. This avoids load on the live system and keeps the data flow one-way out of the control zone.

Which KPIs should be calculated in SQL?

Alarm counts per operator per 10 minutes, peak counts, top frequent alarms, standing alarms, chattering alarms and acknowledgement times. Compute them with queries and let the model explain the results, not produce them.

Is it safe to use for live operator support?

Not as a starting point. Begin with after-the-fact analysis. Real-time advice during an upset needs separate risk assessment and assurance, and the assistant must never replace alarm response procedures.

What if our SCADA exports only CSV?

That works. Load the CSV files into a reporting database on a schedule, map them to a common schema and apply the same KPIs and tools. Keep file integrity checks and time zone handling explicit.

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 Design Scrap and Downtime Reason Codes for MES and ERP

Keep one governed list of reason codes with a small hierarchy, owned in a single system and synchronised to the other. Separate scrap reasons from downtime reasons, mark each downtime code planned or unplanned and each scrap code as process, material, design or operator related, and map codes to ERP accounts or cost categories where accounting needs them. Fewer, clearer codes beat long lists nobody uses correctly.

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.

Advanced

How to add AI to GE Proficy (Historian and Plant Applications) on-prem

Keep Proficy where it is and put a read-only AI layer beside it. The assistant reaches Historian through its documented OLE DB provider or client SDK, reaches Plant Applications through its SQL Server database or a reporting copy, and runs an open-weight model on local GPUs. No tag data leaves the site, and every question and query is logged.

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.

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.

AI for ERP

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

AI for ERP

An Air-Gapped Private LLM for SyteLine, Built for Defense Suppliers

Deploy a private LLM on an air-gapped network alongside Infor SyteLine for defense suppliers: no internet egress, ITAR and CMMC-aware architecture.

Stuck on Plant SCADA alarm and event logs?

Talk to engineers who work inside Plant SCADA alarm and event logs 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