PLC, SCADA and DCS Alarm and Event Logs for Industrial AI

Why public alarm datasets fall short for production models

Public alarm data covers too few sites, too little operator context and, in many cases, no real alarms at all. The best-known open option, the ADIOS / I-NERGY dataset on AI4Europe, holds about 5 million energy management system events, with some subsets tagged by control system operators [1]. That is valuable for prototyping, but it reflects one domain and one alarm philosophy.

The Tennessee Eastman process data used across fault-detection research are simulation runs with injected faults over continuous process variables. They contain no nuisance alarms, no chattering tags, no shelving and no operator acknowledgements, which are exactly what alarm-flood and copilot models must learn. Loghub, the main public log collection, comes from software systems such as distributed systems and supercomputers, not from controllers [4].

Academic work on SCADA alarms, such as alarm-event profiling studies, often relies on private operator data that is not redistributed [2]. If your product is an operator copilot, an alarm-rationalization assistant or a flood root-cause model, plan to license real journals from several plants with different control platforms.

What one alarm journal row should contain

A journal row is an event, not a sensor reading, so the schema is built around state transitions rather than values over time. Continuous process values belong to historian data, covered on our sensor and IoT data page, and should be joined in, not confused with alarms.

Minimum fields to request:

• Event identity: event ID, source system (DCS, SCADA server, PLC, safety system), controller or node pseudonym.
• Tag and condition: tag name, alarm type (HI, HIHI, LO, LOLO, deviation, rate of change, discrete or bad-PV), setpoint or limit at the time, and the process value when triggered if recorded.
• Priority and class: configured priority (for example, low, medium, high, emergency), alarm class, and whether the alarm is safety-related.
• State transition: active, acknowledged, returned to normal, shelved, unshelved, suppressed by design, out of service, and disabled. OPC UA Alarms and Conditions also models shelved, suppressed and out-of-service as states distinct from disabled. A dataset that drops these states hides how operators actually cope with floods.
• Who and where: console, operator position or role (pseudonymized), and area of responsibility.
• Time: source timestamp and server receipt timestamp, with time zone and clock source.

Exports from DCS and SCADA platforms vary widely, from CSV alarm summaries to proprietary journal databases. Practitioners already parse these exports into searchable indexes for offline analysis [3], which is a good sign that suppliers can produce consistent tables.

The context that makes tag names meaningful

Without the master alarm database, tag names such as 21FIC104.PVHI are opaque strings to a model. Ask suppliers for the configuration and documentation that turn tags into meaning:

• Master alarm database (MADB): each alarm's configured limit, priority, deadband, on and off delays, and, where rationalization was done, cause, consequence, corrective action and time to respond.
• Asset hierarchy: plant, unit, area and equipment for each tag, ideally aligned with the ISA-95 hierarchy the plant already uses.
• Control narratives and P&ID references for the units in scope, redacted as needed.
• Change history: when limits, priorities or suppression logic changed. A model trained across a rationalization project will otherwise learn two alarm philosophies as one.

Shelving under ISA-18.2 is operator-initiated, time-limited and subject to engineering controls, while suppressed-by-design is logic-driven by plant state. Capture which mechanism caused each suppression, because a copilot should reason differently about each.

Linking alarms to operator actions, shift logs and work orders

Labels for flood analysis and copilot training come from joining alarms to what people did next. The most useful joins are:

• Operator action journal: setpoint changes, mode changes (auto, manual, cascade), valve and pump commands, with tag and console.
• Shift logs and handover notes: free-text explanations of upsets. See our guide to shift handover logs and operator logbooks.
• Maintenance work orders raised against alarmed equipment, as described on our maintenance work order datasets page.
• Incident and near-miss reports for major upsets, where the plant allows.

With these joins, you can build labeled sequences: a flood window, its probable initiating alarm, the consequential alarms that followed, the operator response and the resolution. That structure is close to network root-cause data; compare our page on NOC alarm and incident logs. It also resembles process event logs, so techniques from process mining event logs carry over.

Alarm-management metrics to screen and label the data

ISA-18.2 and its IEC counterpart, IEC 62682, give a shared vocabulary for scoping a purchase and checking whether a sample is representative. Compute these on any sample before you commit:

• Alarm rate per operator position per hour, overall and in the worst 10-minute windows.
• Flood periods: windows where the rate exceeds your chosen threshold, with start, end and peak.
• Chattering and fleeting alarms: repeated active and return transitions on one tag within a short period.
• Stale alarms: alarms active for a long time without return to normal.
• Top contributors: share of total alarms from the most frequent tags.
• Priority distribution and shelving frequency.

These are also labels. Chattering flags, flood membership and stale status can be derived deterministically, which reduces the human labeling you need. Document derivation rules as part of your data quality process; ISO/IEC 5259-4 frames such a process for training and evaluation data, including labeling [7].

OT security screening before data leaves the plant

Alarm journals can reveal plant layout and control architecture, so security screening is a precondition, not an afterthought. Tag names, controller and node names, IP addresses, network segments and safety-system identifiers can map a facility for an attacker. Expect some critical-infrastructure operators to decline outright.

Ask suppliers to apply, and document, these steps:

• Pseudonymize tags, controllers and nodes with a consistent keyed mapping, preserving tag-type suffixes (PV, HI, HIHI) that carry meaning.
• Remove IP addresses, hostnames, firewall and network identifiers, and any credentials that appear in event text. See our guide on credentials and secrets in log datasets.
• Generalize site location and shift absolute dates if the buyer does not need calendar seasonality.
• Pseudonymize operator IDs. Research on process-mining event logs shows timestamps and resource attributes can make individuals re-identifiable [5], and operator console logs carry the same risk.

Timestamps, clock sync and evaluation splits

Alarm sequences only support root-cause modeling if event order is trustworthy. Controllers, SCADA servers and safety systems may run on different clocks, and some platforms time-stamp at the server rather than the source. Request both timestamps where available, normalize to UTC with the original offset recorded, and ask the supplier to describe clock synchronization (for example, NTP or PTP) and known drift.

Split by time and by site, not by random rows. Random splits of event logs leak information across cases [6], and alarm floods are especially prone because consecutive events share a root cause. For historian joins, use as-of logic, covered in our guide to point-in-time correct training data.

Request template for alarm and event journal data

Use a structured request so suppliers can say quickly whether they hold matching data.

Illustrative example: invented to show structure; it does not describe an available dataset.

Illustrative example: invented to show structure; it does not describe an available dataset.

{"event_id": "e-000184", "site": "SITE_B", "unit": "U300", "tag": "T_7731.PVHI",
 "alarm_type": "HI", "priority": "high", "state": "ACKED",
 "ts_source_utc": "2025-03-14T08:02:11.250Z", "ts_server_utc": "2025-03-14T08:02:11.910Z",
 "console": "CON_2", "operator": "OP_41", "flood_id": "F-0092", "chattering": false}

How SourceX handles alarm and event journal requests

SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing agreements and ongoing purchases. Nothing is held in stock, and a request does not guarantee a match. You describe the data you need, SourceX looks for US businesses that hold it, and every release is approved by the supplying company, which matters for plants weighing OT exposure. Manufacturing-specific context is on our manufacturing buyers page, and you can describe your alarm data requirements directly.

Each dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery. Personal details such as names and account numbers are removed or replaced before delivery, the method is recorded, and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows after an executed agreement and supplier approval.

For neighboring data types, see the industry-specific operational data hub, wind turbine SCADA and O&M records and production log data for anomaly detection.

Source SCADA alarm and event logs for your industrial AI

SourceX finds US companies that hold the alarm, event and operator action data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license before anything transacts. Nothing is contracted until a supplier agrees. Start your alarm and event data request.