ISA-18.2 Alarm Management: Rationalization, Alarm Floods and KPI Targets for Process Plants (2026)

Most control rooms do not suffer from too little information. They suffer from an alarm system that has quietly become a second, noisier historian: every tag that someone once worried about got a limit, every limit became an annunciated alarm, and nobody ever removed one. The operator then has roughly ten minutes during an upset to find the three alarms that matter among a hundred that do not. That failure pattern is why ISA-18.2 alarm management exists, and why it is built as a lifecycle with measurable targets rather than a one-off cleanup project.

It matters in 2026 because plants are connecting more instruments, adding analytics-generated alerts and merging DCS (distributed control system) and SCADA (supervisory control and data acquisition) alarm streams into shared platforms. Without a governing standard, each new source adds load to the same finite human attention. This post walks the ten lifecycle stages, shows how a rationalization session actually turns a tag into a justified alarm, defines floods and the key performance indicators (KPIs), and gives working SQL and Python for monitoring. You will leave with a defensible target set, a design for dynamic suppression and shelving, and a list of the anti-patterns that make good projects decay.

What this covers: the standard and its lifecycle, rationalization workflow and priority distribution, alarm flood mechanics, EEMUA 191 and ISA-18.2 KPI targets, shelving and suppression design, historian analytics code, and the failure modes to avoid.

Context and Background

Alarm management became a formal discipline after a run of industrial accidents in which investigators found operators overwhelmed by alarms in the minutes before the event. The UK Health and Safety Executive’s reviews of the Texaco Milford Haven refinery explosion in 1994 are the most cited example, and they drove the first widely used guidance: EEMUA Publication 191, Alarm systems: a guide to design, management and procurement, from the Engineering Equipment and Materials Users Association. EEMUA 191 gave plants a vocabulary and numbers, but it was a guideline, not a certifiable standard.

ANSI/ISA-18.2, Management of Alarm Systems for the Process Industries, was first published in 2009 and revised in 2016. It turned the guidance into a lifecycle standard with defined work products. The International Electrotechnical Commission then adopted the same framework as the IEC 62682 series, so a plant can cite either document. Read the ISA catalog entry for the current edition and its scope at the International Society of Automation standards page, and treat the standard text itself, not any vendor summary, as the authority for contractual or audit wording.

Two things distinguish the standard from earlier practice. First, it treats the alarm system as a managed asset with an owner, a change process and an audit, much like a safety instrumented function. Second, it separates the alarm (something that requires a timely operator response) from an event, a prompt, or an alert. A great deal of the noise in real plants is simply information that was put in the wrong category.

It is also worth being clear about what the standard does not cover. Safety instrumented systems have their own lifecycle under IEC 61511, and a trip that fires with no operator action is not an alarm in the ISA-18.2 sense. The two interact, because a high-high alarm often sits in front of a trip, but the ownership and testing regimes differ. For the wider industrial data context in which alarm events now travel, see our guide to industrial DataOps architecture between OT and the enterprise, and for how alarm-like notifications look in a utility protocol, the post on DNP3 secure authentication and unsolicited responses.

The practical consequence for a digital twin or analytics team is that alarm data is a first-class dataset. Each alarm record carries a tag, a state transition, a priority, a timestamp, an operator acknowledgment time and often a console assignment. That is a clean, high-value event stream, and the standard’s KPIs are all computable from it with ordinary SQL.

The ISA-18.2 Lifecycle: A Reference Architecture for Alarm Systems

Direct answer: ISA-18.2 defines alarm management as a ten-stage lifecycle: philosophy, identification, rationalization, detailed design, implementation, operation, maintenance, monitoring and assessment, management of change, and audit. The stages form loops, not a line. Monitoring feeds back to rationalization, and every change passes through management of change.

Figure 1: The ISA-18.2 alarm management lifecycle (stages A to J) with the main feedback loops.

The diagram shows why the lifecycle is described as a closed loop. Stages A to E build the system, stages F and G run it, and stages H, I and J keep it honest. The dashed arrows are the ones projects forget: monitoring should trigger re-rationalization of the worst offenders, and the audit should trigger a rewrite of the philosophy when the plant has changed.

Stage A: The alarm philosophy document

The philosophy is the contract. It defines what an alarm is at this site, the classification scheme, the priority levels and the criteria for assigning them, the response-time conventions, the KPI targets, the rules for shelving, suppression and out-of-service, and who may change what. Without it, rationalization sessions degrade into opinion contests, because there is no shared yardstick for “important”.

A good philosophy is short enough to be read. It fixes the number of priority levels (commonly three or four), defines each in terms of consequence severity and time available to respond, and states the target distribution. It also names the roles: alarm system owner, the engineer who administers the master database, and the operations representative who has veto over alarms that cannot realistically be handled.

Stages B and C: Identification and rationalization

Identification gathers candidate alarms from many sources: piping and instrumentation diagrams, hazard and operability studies (HAZOP), layers of protection analysis, incident investigations, operator suggestions and equipment vendor requirements. Rationalization is where each candidate is tested against the philosophy and either becomes a documented alarm or is rejected. We treat it in depth in the next section because it is where the value is created.

Stages D and E: Detailed design and implementation

Detailed design covers three layers. Basic alarm design sets limits, deadbands, delays and the alarm type. Human-machine interface (HMI) design decides how alarms are presented: summary lists, grouping by area, graphics integration, sound, and the visual treatment of priority. Advanced alarming covers the logic that goes beyond a single limit: state-based alarming, first-out, grouped or repeating alarms, and alarm suppression by design. Implementation then installs, tests and trains. The test step matters more than people expect, because a limit entered with the wrong engineering unit is a classic source of an alarm that never fires when it should.

Stages F, G and H: Operation, maintenance and monitoring

During operation, operators respond, and the system supports shelving and acknowledgment. During maintenance, instruments are calibrated and alarms may be placed out of service with controls. Monitoring and assessment is the stage that makes the whole thing a management system: it computes the KPIs described later, compares them to the targets in the philosophy and reports to the people who can act.

Stages I and J: Management of change and audit

Management of change (MOC) ensures that adding, modifying or deleting an alarm goes through the same review as a physical change. The audit periodically checks that the philosophy is being followed, the master database matches the control system, and the documentation is current. A frequent finding is “configuration drift”: the DCS holds limits that differ from the master alarm database because someone made a fast change during a startup.

Why the lifecycle framing beats a cleanup project

Plants often run an alarm “clean-up” with a consultant, achieve a dramatic drop in alarm counts, and see the numbers climb back within eighteen months. The lifecycle explains the regression. Without stage H producing a monthly report, stage I gating changes and stage J verifying compliance, the pressures that created the original mess return: new projects add alarms to hit commissioning deadlines, operators request limit tightening after an incident, and nobody retires obsolete alarms. The standard’s real contribution is making alarm quality someone’s recurring job.

Alarm Rationalization: From Candidate Tag to Justified Alarm

Direct answer: Alarm rationalization is the structured review in which every candidate alarm is tested for operator relevance, classified, prioritized, given a limit and a documented response, and recorded in a master alarm database. An alarm that has no consequence, no required action or no time to act is removed, converted to an event, or redesigned.

Figure 2: The rationalization decision flow, ending in management-of-change approval.

The flow in Figure 2 looks simple, and the first gate does most of the work. The question “does this require an operator action?” eliminates a surprising share of candidates in a typical legacy system. Typical rejects are indications of normal equipment state (pump running), alarms that duplicate another alarm one step upstream, alarms that tell the operator something happened that they themselves just caused, and alarms whose only possible response is “call maintenance tomorrow”, which belongs in a work-management system rather than on the console.

The attributes every rationalized alarm should carry

The master alarm database is the product of rationalization. For each alarm the record should hold, at a minimum: the tag and a plain-language description; the alarm type (high, low, deviation, rate of change, discrepancy and so on); the limit and its engineering unit; the deadband and on-delay or off-delay; the classification (safety, environmental, quality, production, asset protection); the priority; the consequence of inaction; the expected operator response; the allowable response time; the cause list; and the approval date and approver. ISA-18.2 uses the term alarm response time for the time available between the alarm and the point where the consequence can no longer be avoided, and a good rationalization records it explicitly because it drives priority.

Assigning priority from consequence and time

Priority should be derived, not argued. The standard-aligned approach is a matrix with consequence severity on one axis and the time available to respond on the other. A consequence that threatens people or leads to a major release with ten minutes to act lands at the top. A product-quality deviation with an hour to correct lands at the bottom of the active range. Writing the matrix into the philosophy removes the temptation to assign “high” to anything an engineer personally cares about.

The matrix needs a ceiling on severity categories to be usable. Many sites use four consequence categories (for example minor, moderate, major, severe) and three response-time bands, then map the grid to priorities. The exact categories are a site decision and should come from the plant’s existing risk matrix so alarm priorities and risk assessments agree.

Priority distribution: why 80, 15, 5 is a health check

A commonly published guideline in ISA-18.2-aligned practice is that, in a three-priority system, roughly 80 percent of configured alarms are low priority, about 15 percent medium and about 5 percent high. For four priorities the same split applies with an additional highest class kept below about 1 percent. This reference is documented in vendor guidance that summarizes the standard, for example in the Emerson alarm management guide. Treat the percentages as indicators, not rules: they diagnose a system where everything is “high”, but a plant with many genuinely hazardous units may justify a different mix, provided the philosophy records why.

The distribution is the cheapest audit you can run. A system with 45 percent of alarms at the top priority is not a system where 45 percent of alarms are urgent; it is a system where priority carries no information. Operators learn this quickly and begin to ignore the priority, which defeats the purpose of having it.

Limits, deadbands and delays: the quiet noise reducers

After priority, the biggest practical lever is the alarm’s configuration against the signal. A noisy analog signal crossing a limit repeatedly produces a chattering alarm: many activations in a short time, no information. Three standard remedies exist.

A deadband requires the signal to return a set distance past the limit before the alarm clears, so noise around the limit does not retrigger it. An on-delay requires the condition to persist for a set time before the alarm is raised, which filters short excursions. A filter on the measurement smooths the value. Each has a cost: a long on-delay eats into response time, and a heavy filter can hide a real fast excursion. The rationalization team should set them against the dynamics of the process, which is why involving a process engineer who knows the loop is essential. For loop dynamics that interact with limit design, see our guide on PID controller tuning and anti-windup, since an oscillating loop is a common hidden cause of repeating alarms.

Running the session: people, data and time

A rationalization workshop typically needs an operator, a process or area engineer, an instrument or control engineer and a facilitator who knows the philosophy. Per-alarm time is measured in minutes, so the preparation determines throughput. Bring the historian-derived list of the worst bad actors first, because a small number of alarms usually produce a large share of the load. Rationalize those first, then work through the remainder by unit.

A worked illustration, with invented values for demonstration only: suppose a reactor jacket outlet temperature high alarm activates 400 times per month and the operators acknowledge it without acting. The session asks what action the alarm requires. The process engineer says the real concern is a cooling-water flow loss, which has its own alarm. The decision is to remove the temperature alarm as a priority alarm, keep it as a logged event, and tighten the flow alarm. One decision removes 400 monthly activations and sharpens the remaining alarm. This kind of finding is common, but the specific numbers here are illustrative, not measured.

Documenting the response and the cause

An alarm without a documented operator response is an alarm no one has thought through. The response field should be an action the operator can take from the console or by dispatching a field operator, written in short imperative form. The cause list helps newer operators diagnose. When a response cannot be written, that is itself a signal: either the alarm has no valid action and should be removed, or the process knowledge is missing and needs capturing before the alarm can be justified.

Integrating rationalization with HAZOP and layers of protection

The strongest rationalization programs link the alarm database to the process hazard analysis. Where a HAZOP assigns an operator response as an independent protection layer, the alarm behind it needs to meet higher reliability expectations: the operator must have enough time, the instrument must be dependable, and the alarm must not be shelvable without compensating controls. This is the boundary where alarm management meets functional safety, and the philosophy should state explicitly which alarms are safety-related and therefore subject to tighter shelving, testing and change control. Defining that class early prevents the common failure where a critical alarm is shelved routinely because it chatters, with no one noticing that a protection layer was disabled.

Modular and batch contexts

Alarms inside modular or batch plants add a wrinkle: the same equipment is used in different phases, and an alarm meaningful in one recipe step is nonsense in another. That is a natural fit for state-based alarming, covered later. For the structure of batch phases and procedural states that can drive such logic, see our post on ISA-88 batch control and the physical and procedural model, and for modular process units that bring their own alarm handling, the guide to Module Type Package and VDI 2658 orchestration.

Alarm Floods, Operator Capacity and KPI Targets

Direct answer: An alarm flood is a period when alarms arrive faster than an operator can process them. A widely used operational definition from ISA-18.2 practice is more than 10 alarms in a 10-minute window per operator console. Performance is judged with KPIs such as average alarms per hour, peak 10-minute counts, flood time, stale alarms and the share of load from the top few offenders.

Why a flood is a human-factors failure, not a counting trick

Operators can diagnose, decide and act at a finite rate. When the arrival rate exceeds that, alarms are acknowledged without being understood, and the operator is forced to triage by pattern rather than by analysis. Floods are dangerous precisely because they cluster at the worst time: a trip of a major unit produces hundreds of consequential alarms, most of which are symptoms of the first event. The earliest alarm is often the diagnostic one, and it is buried.

Floods have three typical shapes. A cascade flood follows a single cause through connected equipment. A chatter-driven flood comes from one or two oscillating signals producing dozens of activations. A start-up or shutdown flood results from alarms that are valid in normal running but meaningless when equipment is intentionally off or in transition. Each shape has a different remedy, which is why classification of floods precedes design of fixes.

The numbers: ISA-18.2 and EEMUA 191 reference targets

The reference figures most plants use trace to EEMUA 191 and are echoed in ISA-18.2-aligned guidance. A published summary in Control Engineering by Yokogawa, Implementing Alarm Management per the ANSI/ISA-18.2 Standard, gives practical limits to human capability, and the Emerson guide cited earlier lists the same average targets. Together they give:

KPI (per operator console)	Very likely acceptable	Maximum manageable
Alarms per day	about 150	about 300
Alarms per hour, average	about 6	about 12
Alarms per 10 minutes, average	about 1	about 2
Percentage of 10-minute periods with more than 10 alarms	under about 1%	review and act
Maximum alarms in any 10-minute period	10 or fewer
Chattering and fleeting alarms	zero	action plan for any
Stale alarms present on any day	fewer than 5	action plan
Top 10 most frequent alarms, share of total load	up to about 1% to 5%	action plan
Priority split (3 levels)	about 80/15/5 low/medium/high

Note the “about” on every row. These are guideline targets that the plant’s own philosophy should adopt and adjust, not pass-fail limits. A console serving a large, highly automated unit with experienced operators may be reasonable at different levels, which must be justified in the philosophy.

EEMUA 191 revision 3: what changed in the performance view

EEMUA 191 revision 3 was released on 11 September 2013, according to the analysis in Automation.com on revision 3 KPI implications. That article describes two headline measures: a steady-state KPI, the mean alarm rate per 10 minutes with a target of 1 alarm per 10 minutes, and an upset-state KPI, calculated by taking the highest 10-minute alarm count each day and averaging over the month, with a target of 10 alarms per 10 minutes. It also reports that revision 3 reduced the performance-level grid from five levels to four and split the view into separate steady-state and upset charts, so results from the two revisions are not directly comparable unless historical data is recomputed the same way. If your plant compares against older benchmark reports, check which revision they used before drawing conclusions.

I have not reproduced the full revision 3 threshold tables here because the document is a paid publication and the secondary sources I verified do not list every cell. Obtain the guideline directly for contractual use.

Flood start and end: define both ends

A flood needs a start and an end, otherwise “time in flood” is meaningless. The common convention treats a flood as beginning when the count in a rolling 10-minute window exceeds 10 and ending when it falls back below a lower threshold, commonly 5 in 10 minutes, to prevent rapid toggling. Check the exact wording in your copy of the standard or your technical report and write it into the philosophy; the end threshold in particular varies in practice and I could not verify a single authoritative value from the sources available for this post.

Two derived metrics are far more useful than raw rates. Flood event count tells you how many separate incidents occurred, and alarms per flood tells you how severe each was. A plant with few but enormous floods has a different problem (usually cascading consequential alarms) from one with many small floods (usually chatter and poor start-up logic).

Stale alarms and chattering alarms

A stale alarm is one that has been active and unacknowledged or simply standing for an extended period, commonly measured against a 24-hour threshold. A list full of standing alarms trains operators to scroll past the list. The fix is rarely an operator action: stale alarms are mostly out-of-service equipment, bad instruments or alarms whose cause is a known long-running condition, all of which belong in the maintenance or shelving process with an owner and an expiry.

A chattering alarm repeatedly goes active and clear in a short period. The standard defines a repeat-count threshold within a time window; teams commonly flag three or more activations within a minute as chattering. Because the exact threshold is a configuration choice, state it in the philosophy. A fleeting alarm activates and clears faster than it can be perceived, and it is also a signal of a poorly specified limit or delay.

Operator load is not just count

Counts mask an important subtlety: not every alarm costs the same. A well-understood, single-action alarm consumes seconds; a novel multi-step alarm consumes minutes. KPIs should therefore be read together with qualitative inputs: operator surveys, post-incident reviews and walk-throughs of the highest-priority alarms. A console can meet every number and still be hard to operate if related alarms are scattered across displays or the alarm text is cryptic.

Good alarm text states the condition and the direction, avoids abbreviations the operator does not use, and puts the unit or equipment name first so the summary list sorts meaningfully. This is cheap to fix during rationalization and expensive afterward.

Shelving, Suppression and Dynamic Alarming in Practice

Direct answer: ISA-18.2 distinguishes three ways an alarm can be kept off the operator’s screen: shelving (a temporary, operator-initiated hide with a timer), suppression by design (logic-driven hiding because the alarm is not meaningful in the current state), and out-of-service (removal by maintenance process while equipment is unavailable). Each has different authority, time limits and audit rules.

Figure 3: Plant state drives dynamic alarm attributes and suppression, with operator shelving as the last resort.

Shelving: the operator’s pressure valve

Shelving lets an operator temporarily hide a nuisance alarm so the list stays usable. A compliant implementation records who shelved it, why, and for how long; automatically returns it to the list after a maximum time; and keeps a visible shelved-alarm count so the practice is not hidden. Some platforms also support automatic shelving after an alarm has been active for a preset time, with access control on who can enable it. Vendor descriptions of such features appear in the Emerson guide referenced above.

The risk is obvious: shelving is the easiest way to quietly disable a protection layer. Controls that work in practice are a short default shelve time, a ceiling on how many alarms one operator may shelve, mandatory reason codes, a supervisor review of long shelves, and a rule that safety-related alarms cannot be shelved without a compensating measure. A KPI for “shelved alarms present” belongs on the monthly report next to stale alarms, because a growing shelved list is stale alarms in disguise.

Suppression by design: state-based logic

Suppression by design hides an alarm automatically when logic says it cannot be meaningful, for example a low-flow alarm on a pump that is intentionally stopped. It is the right tool for cascading consequences: when a main feed pump trips, downstream low-level and low-flow alarms are expected and carry no new information. Suppressing them leaves the operator looking at the cause.

Three design rules keep suppression safe. The suppression condition must be based on a reliable, preferably redundant, state signal. The suppression must be visible somewhere (a “suppressed by design” indicator or a diagnostic page), so engineers can see what is hidden. And the logic must be rationalized and approved like any alarm, because suppression logic is itself a path to missing a real event if the state signal is wrong.

Dynamic alarming and the state-based model

Dynamic alarming, also called state-based alarming, changes alarm attributes automatically as the plant state changes. Figure 3 sketches the pattern: a state model derived from unit mode, equipment status and key flows selects a rule set. In running mode the full normal limits apply; during startup, limits may relax or on-delays lengthen; in shutdown, downstream alarms are suppressed; during an upset, the display favors first-out and top-priority alarms.

The state model is the hard part, not the alarm logic. It needs a trustworthy definition of “startup” and “shutdown”, and those definitions often live in the heads of operators or in batch phase logic. Where an ISA-88 or MTP phase model already exposes unit state, reuse it instead of inventing a parallel state machine. When state is derived from thresholds on process values, add hysteresis so the state itself does not chatter and drag alarms with it.

Dynamic alarming is also the main route to reducing start-up and shutdown floods, which static rationalization cannot fix because the same alarm is legitimate in one state and noise in another. The failure to watch is state misclassification: if the system believes the unit is in shutdown when it is running, protective alarms may be suppressed. Test the state logic with simulation or historical replay before commissioning.

First-out and grouping

First-out logic identifies which alarm in a related set occurred first and marks it, because in a trip the first alarm is usually closest to the cause. Grouping and repeating-alarm logic collapse many related alarms into a single annunciated group alarm with drill-down. Both are advanced alarming techniques named in the lifecycle’s detailed design stage. They are only as good as the timestamp resolution: if your alarm and event journal timestamps at one-second resolution and a trip produces twenty alarms in that second, the sequence is lost. Where sequence matters, use controller-level or sequence-of-events (SOE) timestamping and make sure clocks are disciplined. Our guide to PTP IEEE 1588 versus NTP and chrony explains the synchronization side.

Out-of-service and maintenance interplay

An alarm placed out of service no longer performs its function, and the standard treats this as a transition from operation to maintenance. The control is a work order or equivalent authorization, an owner, an expiry and a periodic report of everything currently out of service. Without an expiry, out-of-service becomes the permanent home of every alarm someone found annoying once.

Comparing the three mechanisms

Mechanism	Triggered by	Typical authority	Time limit	Main risk
Shelving	Operator (or timed auto-shelve)	Operator, with reason	Short, auto-return	Quiet loss of a protection layer
Suppression by design	Plant-state logic	Engineering, via MOC	Continuous while state holds	Wrong state signal hides real alarm
Out of service	Maintenance process	Work permit and approver	Until repair, with expiry	Never returned to service

Monitoring and Analytics: KPIs From Historian and Event Data

Direct answer: Every ISA-18.2 KPI can be computed from a table of alarm activations with a tag, priority, console, and timestamp. Rolling 10-minute counts give flood detection; daily counts per console give load; grouping by tag gives the top offenders; and activation durations give stale-alarm candidates.

Figure 4: The analytics pipeline from DCS event journal to KPI reports and back into management of change.

The pipeline in the figure has a simple shape. Export the alarm and event journal from the DCS or SCADA historian into an event store, clean it, assign each alarm to an operator console, compute KPIs and flood episodes, and send a prioritized worklist of bad actors back into the rationalization and MOC process. The loop is the point: analytics that never changes the alarm database is only reporting.

Data preparation: the unglamorous 70 percent

Raw journals are messy. The same alarm can appear as an activation, an acknowledgment, a return to normal and a return-acknowledged record, each as a separate row. Before computing KPIs, normalize to one row per activation with an active_ts, an optional ack_ts and an optional clear_ts. Check for duplicate rows from redundant servers, clock steps, and alarms with no matching clear (these are stale candidates or lost messages). Decide whether to count shelved or suppressed activations in load; most KPI definitions count only annunciated alarms, so you need the annunciation flag.

Console assignment matters because the standard’s targets are per operator position. A plant-wide count divided by the number of operators hides an overloaded console. Maintain a tag-to-console mapping table and update it when areas are re-allocated.

SQL: rolling 10-minute counts and flood time

The following PostgreSQL-style query computes the number of alarms in each 10-minute bucket per console, then flags buckets above the flood threshold. It assumes a table alarm_activation(console text, tag text, priority int, active_ts timestamptz). Fixed buckets are simple; a sliding window is more faithful and is shown in the Python example.

WITH buckets AS (
  SELECT console,
         date_bin('10 minutes', active_ts, TIMESTAMPTZ '2026-01-01') AS bucket,
         COUNT(*) AS n
  FROM alarm_activation
  WHERE active_ts >= now() - interval '30 days'
  GROUP BY console, bucket
)
SELECT console,
       COUNT(*)                                        AS buckets_with_alarms,
       COUNT(*) FILTER (WHERE n > 10)                  AS flood_buckets,
       MAX(n)                                          AS max_per_10min,
       ROUND(100.0 * COUNT(*) FILTER (WHERE n > 10)
             / (30 * 24 * 6), 2)                       AS pct_time_in_flood
FROM buckets
GROUP BY console
ORDER BY flood_buckets DESC;

The denominator of 30 * 24 * 6 is the number of 10-minute periods in 30 days, so the percentage is over all time, not only over buckets that contained alarms. That detail is a frequent bug: dividing by buckets-with-alarms inflates the apparent flood share.

SQL: top offenders and the Pareto

SELECT tag,
       COUNT(*) AS activations,
       ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct_of_load,
       ROUND(100.0 * SUM(COUNT(*)) OVER (ORDER BY COUNT(*) DESC)
             / SUM(COUNT(*)) OVER (), 1)               AS cumulative_pct
FROM alarm_activation
WHERE console = 'UNIT1'
  AND active_ts >= now() - interval '30 days'
GROUP BY tag
ORDER BY activations DESC
LIMIT 10;

In many plants the top ten tags dominate the total, which is why the standard tracks their share. If the ten most frequent alarms carry a large fraction of the load, fixing them is the highest-return work you can do. Bad-actor lists are also where the earlier ten-minute chatter patterns reveal themselves.

Python: sliding-window flood episodes with hysteresis

This version detects flood episodes using a rolling 10-minute window, a start threshold and a lower end threshold. The thresholds are parameters because, as noted, the exact end value should come from your philosophy.

import pandas as pd

def flood_episodes(df, start_gt=10, end_lt=5, window="10min"):
    """df: columns console, active_ts (datetime). Returns episodes per console."""
    out = []
    for console, g in df.sort_values("active_ts").groupby("console"):
        s = pd.Series(1, index=pd.DatetimeIndex(g["active_ts"]))
        counts = s.rolling(window).sum()           # alarms in trailing 10 min
        in_flood, start, peak = False, None, 0
        for ts, n in counts.items():
            if not in_flood and n > start_gt:
                in_flood, start, peak = True, ts, n
            elif in_flood:
                peak = max(peak, n)
                if n < end_lt:
                    out.append((console, start, ts, int(peak)))
                    in_flood = False
        if in_flood:
            out.append((console, start, counts.index[-1], int(peak)))
    return pd.DataFrame(out, columns=["console", "start", "end", "peak_10min"])

df = pd.read_parquet("alarm_activation.parquet")
eps = flood_episodes(df)
eps["minutes"] = (eps["end"] - eps["start"]).dt.total_seconds() / 60
print(eps.groupby("console").agg(floods=("start", "count"),
                                 minutes_in_flood=("minutes", "sum"),
                                 worst_peak=("peak_10min", "max")))

A caveat on this implementation: the trailing window only changes when a new alarm arrives, so the end of a flood is detected at the next activation after the burst, not exactly when the count drops. For precise durations, resample to a regular one-minute grid before applying the hysteresis. For reporting at monthly granularity the approximation is usually acceptable.

Chattering and stale detection

Chattering candidates are tags with many activations within short repeat windows; stale candidates are activations whose duration exceeds the stale threshold, or activations with no clear record.

-- chattering: three or more activations of one tag within 60 seconds
SELECT tag, COUNT(*) AS chatter_events
FROM (
  SELECT tag, active_ts,
         COUNT(*) OVER (PARTITION BY tag ORDER BY active_ts
                        RANGE BETWEEN INTERVAL '60 seconds' PRECEDING
                                  AND CURRENT ROW) AS recent
  FROM alarm_activation
) t
WHERE recent >= 3
GROUP BY tag
ORDER BY chatter_events DESC;

From KPIs to action: the monthly review

The numbers are only valuable if a meeting acts on them. A workable cadence: weekly bad-actor triage by the control engineer; monthly KPI report to the operations manager; quarterly review of priority distribution and shelved/out-of-service lists; annual audit against the philosophy. Each report should show trend against target, the top ten offenders, flood episodes with a cause note, and the actions closed since the previous period. Link flood episodes to the process event that caused them, because that mapping is what lets rationalization teams design suppression and state logic instead of guessing.

Where digital twins and AI help, and where they do not

Event data from alarm journals is a natural input for analytics: clustering floods by their alarm sequences, finding precursor patterns, and recommending suppression candidates. A simulator or digital twin can replay a trip scenario and show which alarms a candidate design would produce, long before commissioning. These uses are promising, but the recommendations remain proposals for the rationalization team, not automatic changes, because the alarm database is a controlled document. For agent-style analysis of industrial data, see agentic digital twins for industrial analysis. A related statistical discipline for signal-quality monitoring is covered in the post on statistical process control and control charts for IIoT, which can feed better deviation alarms than fixed limits.

Trade-offs, Gotchas, and What Goes Wrong

Alarm programs fail in predictable ways, and most failures are organizational rather than technical.

Counting alarms as the goal. Driving the raw count down is easy: widen limits, add delays, shelve liberally. Doing so can degrade safety while the dashboard improves. Pair every count KPI with an audit of the response-time budget, so a longer on-delay is checked against the time the operator actually has.

Rationalizing without operators. Engineers alone produce alarms that are technically correct and practically unusable. An operator in the room catches “we never act on that” in seconds. Conversely, operators alone tend to remove alarms that have safety value but have not recently mattered, which is why the process safety review must also be present.

Shelving as policy. If shelved counts grow quarter after quarter, shelving has become the real alarm management strategy. Treat the shelved list as a defect list with owners.

Suppression with an unreliable state signal. State-based logic is only as good as the signal. A transmitter that fails to a value interpreted as “unit stopped” can hide the alarms you most need. Use redundant or validated signals, and fail toward showing alarms.

Configuration drift. The master database and the control system diverge when emergency changes bypass MOC. Run an automated comparison of DCS configuration against the master database on a schedule; any difference is an audit finding or a database update, never ignorable.

Vendor defaults and project handover. New projects often deliver thousands of alarms at default limits because the commissioning schedule has no time for rationalization. Make rationalization a contractual deliverable with a completion gate, rather than a post-handover chore that never gets funded.

Mixing alarm types. Prompts, advisory alerts from analytics, and equipment-health messages end up in the same list as process alarms. The standard’s discipline is to keep the alarm list for items needing timely response and route the rest elsewhere. Analytics-generated alerts, including ones from machine-learning models, should enter the alarm system only after rationalization, with a defined response.

Treating the standard as a certificate. ISA-18.2 is a management framework. Claiming compliance means producing the work products: a philosophy, a master database, a monitoring report, an MOC record and an audit. Vendors may state that their tools support the standard, but compliance is a property of how the plant runs, not of the software.

Security and integrity. The alarm configuration is a high-impact target. Unauthorized changes to limits or suppression logic can blind operators without touching a safety system, so protect the master database and the engineering workstation like other control assets. Our posts on OPC UA security certificates and trust lists and NERC CIP and IEC 62443 mapping cover the surrounding controls.

Practical Recommendations

Start with data, not workshops. Pull ninety days of alarm and event history, compute the KPIs per console against the table above, and list the top twenty offenders and every flood episode. That baseline tells you whether you have a chatter problem, a cascade problem or a start-up problem, and each calls for a different first move.

Write a short philosophy before touching alarms. Fix priority levels, the consequence-and-time matrix, the target distribution, the KPI targets, the shelving and out-of-service rules, and the MOC path. Keep it under about twenty pages so people read it.

Rationalize the bad actors first, then by unit in order of risk. Capture response, cause, consequence and response time for every alarm that survives. Use deadbands, on-delays and filters on chatterers before rewriting limits. Then add state-based suppression for start-up, shutdown and cascade floods, using a state signal that already exists in the control system.

Stand up the monitoring pipeline in parallel so improvement is measured, not asserted. Report monthly, review quarterly, audit annually, and gate every change through MOC.

A closing checklist:

Philosophy approved, with priority matrix and KPI targets.
Baseline KPIs per console computed from 30 to 90 days of data.
Alarm type separation: alarms, events, prompts and analytics alerts routed correctly.
Master alarm database complete for all rationalized alarms, with response and response time.
Priority distribution checked against the roughly 80/15/5 indicator.
Chatter, fleeting and stale alarms tracked with owners.
Shelving limited, time-boxed, audited; safety-related alarms controlled.
Suppression by design documented, tested by replay or simulation.
Time synchronization adequate for sequence analysis.
Monthly report, quarterly review, annual audit scheduled.

Frequently Asked Questions

What is ISA-18.2 alarm management?

ISA-18.2 is the ANSI/ISA standard titled Management of Alarm Systems for the Process Industries, first published in 2009 and revised in 2016. It defines a ten-stage lifecycle from philosophy through audit, with work products such as an alarm philosophy document and a master alarm database. The IEC 62682 series adopts the same framework internationally. It is a management process, not just a set of settings.

What is an alarm flood and how is it measured?

An alarm flood is a period when alarms arrive faster than an operator can process them. A commonly used operational definition in ISA-18.2 practice is more than 10 alarms in 10 minutes per operator console. Plants track the number of flood episodes, the percentage of time in flood, and the peak 10-minute count. Targets are typically that flood time stays under about one percent of the period.

What are the EEMUA 191 alarm KPI targets?

EEMUA 191 and ISA-18.2-aligned guidance commonly cite about 150 alarms per operator per day as very likely acceptable and about 300 as the maximum manageable, roughly 6 and 12 per hour, and about 1 and 2 per 10 minutes. Revision 3 of EEMUA 191 also describes a steady-state target of 1 alarm per 10 minutes and an upset-state target of 10 alarms per 10 minutes. Treat them as guidelines to justify locally.

What is the difference between alarm shelving and suppression?

Shelving is a temporary, operator-initiated hide of an alarm, with a reason, a timer and an audit record. Suppression by design is automatic, logic-driven hiding because the alarm is not meaningful in the current plant state, such as a low-flow alarm on a stopped pump. Suppression is engineered and approved through management of change; shelving is an operational control and must be monitored for abuse.

What is alarm rationalization and how long does it take?

Rationalization is the structured review that tests each alarm for operator relevance, classifies and prioritizes it, sets limits and delays, records the response and consequence, and enters it in the master database. Duration depends on alarm count and preparation, since per-alarm review is measured in minutes. Starting with the data-driven list of bad actors typically delivers most of the benefit early.

Is a good alarm count enough to claim ISA-18.2 compliance?

No. Meeting KPI targets shows the system performs well, but compliance means operating the lifecycle: an approved philosophy, rationalized alarms in a master database, monitoring reports, a management-of-change process and periodic audits. A plant could have a low alarm count by widening limits unsafely and still fail an audit, so counts must be read alongside response-time and consequence records.