MES Alarm Management: ISA-18.2, Smart Alerting & Escalation

What MES alarm management really is

MES alarm management is the discipline of capturing abnormal conditions from the shopfloor — machine faults, process deviations, quality failures, safety events — and turning them into targeted actions that reach the right person at the right time with the right information to act. The definition sounds simple; the execution is where plants routinely get it wrong, because alarm management sits on exactly the boundary between operational technology and information technology that most MES deployments underestimate. A PLC fault bit flipping high is not automatically a meaningful alarm. An operator's phone buzzing is not automatically a correct escalation. Between the fault bit and the buzzing phone lies an architectural layer that, if designed casually, produces the single most common failure mode I see in MES projects: a system technically generating thousands of alarms per day that nobody reads, trusts, or acts on.

I have been building the IT/OT bridge since 1991 — first with Simatic S5 and COROS visualisation at an engineering office, then commissioning paint lines and process plants across Eastern Europe and China, then eleven years running SYMESTIC's automation-technology department and the last six as MES consultant connecting brownfield machines from the mid-1990s alongside OPC-UA-equipped 2024-model assembly lines. The alarm-management pattern that works has not changed in those thirty-four years. The tooling has changed completely — COROS SCADA to OPC UA Alarms & Conditions, hardwired 24 V signal towers to MQTT Sparkplug B, desk telephones to mobile apps with geofencing — but the underlying principle holds: an alarm only earns the right to exist if a human or automated responder can do something about it. Everything else is noise, and noise trained operators to ignore signals is the worst outcome a system designed to improve reaction time can produce.

The four-layer alarm stack — where alarms live matters

The single biggest source of confusion in alarm-management conversations is that "alarm" means four different things at four different architectural layers, and plants that treat them as interchangeable build systems where events generated at one layer never cleanly reach the layer responsible for acting on them. The four-layer model, aligned with ISA-95, keeps the responsibilities clear.

The practical implications of this separation: a PLC alarm that stays at L2 never reaches the production manager's phone; an MES alarm without a PLC source has nothing to correlate against and becomes manual data entry; an Andon signal without an MES event trail disappears the moment the tower light goes green again. The system that works is the one where events flow cleanly through all four layers — the PLC detects, the SCADA filters and annotates, the MES correlates with business context and drives workflows, the Andon provides the human-visible shopfloor signal — with each layer adding value without duplicating the layer below. Plants that collapse layers 2 and 3 into a single undifferentiated "alarm system" invariably end up with either flood (everything escalated) or silence (nothing correlated), and both failure modes cost more in downtime than the system they replaced.

ISA-18.2 / IEC 62682 — the lifecycle model that makes alarms behave

The standard that most manufacturing plants outside oil-and-gas have never heard of, and that every serious alarm-management system implements whether it advertises the fact or not, is ISA-18.2 (published 2009, updated 2016; internationally harmonised as IEC 62682). It defines a ten-state alarm lifecycle that turns "an alarm" from a single boolean flag into a traceable workflow with deterministic transitions. Understanding the lifecycle is the difference between an alarm system that can be audited and one that cannot.

The crucial distinctions that plants without an alarm philosophy routinely collapse: Shelved is time-bounded and operator-initiated, Suppressed by Design is automatic and state-driven, Out-of-Service requires formal approval and is the only one that persists across shifts without explicit re-authorisation. The alarm system that treats these as the same state cannot explain in audit why a critical alarm did not fire on the day of a quality incident — because there is no audit trail distinguishing "operator silenced it for 30 minutes" from "engineering disabled it six months ago and forgot." Every mature alarm-management deployment I have worked on starts from the ISA-18.2 state machine and treats everything else as implementation detail. The state machine is not decoration; it is the auditable core of the system.

EEMUA 191 — the benchmark numbers that define "acceptable"

EEMUA 191 (Engineering Equipment and Materials Users Association, Publication 191, "Alarm Systems — A Guide to Design, Management and Procurement," first published 1999, currently in its 4th edition) is the quantitative counterpart to the ISA-18.2 qualitative framework. It defines the numeric benchmarks that separate a functional alarm system from a dysfunctional one, and the numbers are remarkably consistent with what I observe in manufacturing plants when we connect the first MES alarm instrumentation and baseline the reality.

The priority distribution is the most operationally revealing metric in the table. The 5/15/80 target is not arbitrary — it reflects a human cognitive reality: an operator can only attend to a small number of high-priority events per shift. When priority inflation flattens the distribution toward 30/40/30, every alarm carries roughly equivalent visual and cognitive weight, which means the system has communicated no priority at all. The alarm philosophy exercise that precedes any real deployment must answer the question "what does 'high priority' actually mean at this plant?" before priority assignments begin, or the finished system will replicate the priority-inflation pattern of the plant's inherited assumptions.

The three chronic anti-patterns — with measurable diagnostic criteria

An alarm system goes wrong in one of three characteristic ways, each with a quantifiable definition that lets you detect the problem programmatically rather than by operator complaint. Every mature alarm-management platform includes these three detectors as standard dashboard elements, because without them the system's own health is invisible to the humans running it.

Time delay, deadband and hysteresis are the three suppression techniques that eliminate most chattering in practice. Time delay (the alarm only fires after the condition persists for N seconds) handles transient spikes; typical values are 2–5 seconds for mechanical process variables, 10–30 seconds for thermal. Deadband (the return-to-normal threshold is offset from the alarm threshold) handles measurements that oscillate around a setpoint; typical deadband is 2–5% of the alarm setpoint. Hysteresis (different setpoints for entering and leaving the alarm state) combines the two for continuous analog signals. A plant that finds itself with 10–20% chattering alarms in the population is almost always missing one or more of these three at a substantial share of alarm tags, and the fix is a one-time rationalisation exercise per machine rather than a permanent operational problem.

Capture mechanics — how alarms actually get out of a machine

This is the part of alarm management that the typical MES glossary entry never addresses, and the part that in real brownfield projects consumes 60–80% of the engineering effort. The capture-mechanism tree for industrial machinery, ordered from modern to legacy:

The strategic reality behind this table: most plants have a mixed fleet spanning all six mechanisms. The S7-1500 line installed in 2023 publishes OPC UA A&C events with full structured metadata; the S5-based press adjacent to it has three dry contacts wired to a terminal block that communicate everything the press is willing to say about its state. A serious MES alarm-management implementation has to normalise all six inputs into a single coherent event model at layer 3, because downstream consumers — escalation workflows, Andon, dashboards, KPIs — cannot treat the press differently from the line when business context requires the same attention. The normalisation work is unglamorous, it is where brownfield projects succeed or fail, and it is the reason why "just connect the machines" is not a statement of project scope but a decade-long engineering discipline compressed into a sentence.

From a fully automated assembly-line deployment, Southwest Germany, 2022: a customer producing flow regulators and backflow preventers for the sanitary industry. Four assembly lines, each a 20-station synchronous machine with vision inspection, ultrasonic leak testing and torque-controlled screwdriving, connected to a Siemens S7-1500 line-level PLC that exposed an OPC UA server with A&C profile. Textbook modern setup — on paper. The project started with the customer's engineering team confident that connecting the alarm channel was a two-day job because the OPC UA server was already running. The first day we enumerated the alarm tags exposed by the S7-1500 and the number came back 847. Eight hundred forty-seven distinct alarm tags defined on a single assembly line. When we asked the controls engineer which ones mattered, the answer was the one I expect now because I have heard it on every sufficiently complex machine: "I don't know, the OEM set them up, we've never looked at the full list." We ran the line under normal production for a week with everything forwarded to the MES without filtering and the event count came to approximately 18,000 transitions per day across those 847 tags. The alarm flood metric was off the scale, the standing-alarm count was running at 42 persistent unacknowledged tags, and the operators had long since stopped looking at the control-room display because the noise-to-signal ratio had trained them to expect nothing useful. The rationalisation exercise that followed was the most instructive six weeks of that project. We worked through every one of the 847 tags with the maintenance lead, the controls engineer and the shift supervisor, asking three questions per tag: does this condition require human action, if yes who takes that action, and what action specifically do they take. The answers classified the 847 into 74 tags where the answer to all three was clear and defensible, 312 tags where the condition was a diagnostic signal useful for engineering analysis but not operator action, 198 tags that were redundant duplicates of other tags or sequence artefacts, and 263 tags that nobody in the room could explain including the controls engineer who had configured most of them four years earlier. The 74 "real alarms" we routed to the MES event layer with structured priorities, escalation paths and documented operator responses. The 312 diagnostic signals we kept captured in the process-data layer but did not surface as alarms — they remained available for engineering analysis without reaching operator attention. The 461 others we marked for formal Out-of-Service via change control with written justification, and the change-control log is still the document I reference when someone asks whether alarm rationalisation produces measurable results. The new steady-state alarm rate on the line after rationalisation was 0.4 alarms per 10 minutes per operator against the previous 12. The operators started looking at the display again within about three weeks because the alarms that appeared were consistently actionable, and the MTTA (mean time to acknowledge) metric dropped from roughly 14 minutes in the pre-rationalisation baseline to under 90 seconds in the first month after, which had a direct and measurable effect on line availability because the acknowledge-to-fix loop was no longer competing for operator attention with 800 parallel irrelevant signals. The lesson I now state on every project kickoff, because it is the pattern that repeats independently of industry: the machine is not sending you too few alarms, it is sending you too many, and the engineering work that pays back is not adding capture but filtering what is already captured down to the set that deserves human attention. Alarm management is a subtraction discipline, not an addition one, and the plants that understand this are the plants whose systems the operators actually read.

The escalation tree — routing logic that survives contact with reality

Escalation without routing logic is not escalation, it is broadcast. The escalation tree that works has four design parameters that together determine whether alarms reach the right responder at the right time or fail quietly in one of several common failure modes.

1. Role-based routing, not person-based. Escalate to "shift leader on duty line 4" rather than to "Thomas Weber." People go on vacation, change roles, leave the company; the escalation definition that breaks when an individual changes status is the escalation definition that fails silently during the worst three-week holiday of the year.
2. Working-hours awareness. The tree has to know which shifts are running and which are not. A high-priority alarm at 03:30 during a planned maintenance weekend has to behave differently from the same alarm during normal production; the tree that cannot distinguish the two will either escalate to an empty shift (silence) or page a maintenance engineer who is on the factory floor anyway (noise).
3. Timeout handoff with defined levels. If the first-level responder does not acknowledge within the defined window, the alarm escalates automatically to the next level — typically shift leader → production manager → plant manager — each level with its own timeout. The pattern that works in most discrete manufacturing plants is 3–5 minutes to first acknowledgement, 15 minutes to resolution-start, 60 minutes to plant-manager awareness, with priority-specific override. Getting these timings wrong in either direction produces either escalation fatigue (too short) or critical events that sit unattended for hours (too long).
4. Skill-matched routing. A torque-calibration fault goes to the quality engineer; a hydraulic-pressure fault goes to the maintenance engineer; a material-flow fault goes to the production planner. The escalation that treats all alarms as equivalent routing targets wastes the specialist skills that exist in the plant and teaches each specialist to tune the others out.

The fifth parameter, often missing in first-generation escalation designs: the Andon-integration point. A physical tower light going red at the line is a signal nobody can acknowledge remotely; the supervisor who is thirty metres away looking at the line sees it first and starts walking. If the MES escalation tree does not consume the Andon state (light went red at 14:37) as input, it will either generate a duplicate escalation forty-five seconds after the supervisor is already at the machine, or it will miss the event entirely if the tower light was the only signalling channel. A well-integrated system uses the Andon state as both an escalation source (light red = alarm active) and a suppression source (supervisor physically at the machine = do not escalate further), which requires either location awareness on the operator's mobile device or a deliberate acknowledgement-at-the-machine workflow.

The alarm-to-stoppage attribution rate — the KPI most plants do not measure

The alarm-management KPI that matters more than any of the standard EEMUA metrics in the context of MES — and that I now recommend as a standard dashboard element — is the alarm-to-stoppage attribution rate: the percentage of stoppages over 60 seconds that have at least one correlated alarm event in the MES alarm log within the 2-minute window preceding or during the stoppage. The number is trivially calculable once the MES has both alarm capture and stoppage detection (via counter-stop or digital I/O), and it exposes the quality of the alarm-capture instrumentation more directly than any other metric.

The empirical pattern: plants with fully instrumented modern lines typically run attribution rates of 75–90 %; the other 10–25 % are stoppages with no alarm signal — typically operator-initiated stops, product changeovers, or mechanical faults that the PLC did not detect. Plants with brownfield instrumentation typically run 30–55 %; the majority of stoppages have no associated alarm because the capture mechanism is not seeing the fault. The gap between the two is the improvement opportunity, and it is the number that should drive investment priority. Improving alarm-capture coverage from 30 % to 70 % attribution delivers more measurable operational benefit than almost any other alarm-management investment, because it turns invisible downtime into explainable downtime and explainable downtime is the only kind that can be systematically reduced.

How this fits into the SYMESTIC platform

SYMESTIC implements alarm management on the ISA-18.2 state machine as the non-negotiable core — every alarm captured at the MES layer carries the full ten-state lifecycle with deterministic transitions, auditable shelving/suppression/out-of-service distinctions, and cryptographic time correlation so that audit queries like "which alarm fired at 14:37:12 on Line 4 during the production of Unit S/N 4711-2847" return an unambiguous answer rather than a best-effort reconstruction. The capture layer normalises all six mechanisms listed above — OPC UA A&C, OPC UA fault-bit subscriptions, MQTT Sparkplug B, Simatic S7 direct-read, digital I/O gateways, counter-derived synthetic events — into a single coherent event model at ISA-95 Level 3, which is the architectural decision that lets the line installed in 2023 and the press from 1995 drive the same escalation workflows, the same Andon signalling and the same KPI calculations. The three anti-pattern detectors (flood, chatter, stale) run continuously on the alarm stream with EEMUA-aligned thresholds as standard dashboard elements, because a system that does not monitor its own health produces the kind of quiet degradation that the Southwest-German assembly-line story illustrates. The escalation engine supports role-based routing with Azure-Active-Directory-integrated role membership, working-hours awareness per shift calendar, multi-level timeout handoff, skill-matched routing per alarm class, and bidirectional Andon-state integration — both as escalation source and as suppression source when the supervisor is physically at the machine. The alarm-to-stoppage attribution rate is exposed alongside OEE, predictive quality KPIs and schedule adherence, because the three together give the production leader a single dashboard answer to the question "how much of what is going wrong can I actually see", which is the question that determines whether the whole MES investment compounds over time or plateaus at the level of what the first-year instrumentation happened to cover. See also process documentation for the upstream process-definition model that supplies the context alarms are correlated against, and change control for the governance layer around Out-of-Service transitions.

FAQ

What is the difference between a PLC alarm and an MES alarm?
A PLC alarm is a raw fault bit inside the controller — motor overload, interlock violation, sensor timeout — in terms the controller understands. An MES alarm is a business-contextualised event correlated with the order, the operator, the shift and the material lot at the moment of the fault, routed through an escalation workflow defined at the manufacturing-execution layer. The two live at different ISA-95 levels (Level 2 vs Level 3) and serve different audiences: the PLC alarm drives controls engineering, the MES alarm drives production decisions. Serious alarm-management systems make both visible simultaneously without confusing them, because a plant that treats them as the same thing ends up with either flood (every PLC bit escalated to management) or silence (no business context on fault events).

What is ISA-18.2 / IEC 62682 and why does it matter?
ISA-18.2 (internationally harmonised as IEC 62682) is the management-of-alarm-systems standard published by the International Society of Automation in 2009, updated 2016. It defines a ten-state alarm lifecycle, formal rationalisation methodology, alarm philosophy document requirements and audit-trail expectations. It matters because it distinguishes between shelved alarms (time-bounded operator suppression), suppressed-by-design alarms (state-based automatic silencing) and out-of-service alarms (formally disabled with management approval) — three situations that behave completely differently in audit but that uninstrumented systems typically collapse into a single "silenced" category. Regulated industries (pharma GMP Annex 11, oil & gas) effectively require ISA-18.2 compliance; non-regulated industries benefit from it because the state machine is the only reliable way to make alarms auditable across shifts and operator changeovers.

What are EEMUA 191 alarm-rate benchmarks?
EEMUA 191 is the British engineering guidance document for alarm-system design, now in its 4th edition. Its key quantitative benchmarks: steady-state alarm rate below 1 alarm per 10 minutes per operator, upset-peak rate below 10 per 10 minutes, standing alarm population below 10 per operator, chattering alarms eliminated, priority distribution roughly 5% high / 15% medium / 80% low. These numbers define what a functional alarm system looks like; plants that measure for the first time typically discover they are running 5–20× above these thresholds, which is the EEMUA-predictable cause of the operator-ignores-everything failure mode. The benchmarks apply across industries — discrete manufacturing, process, batch — with only minor adjustments.

How do I prevent alarm flood in my MES?
Three techniques in descending order of impact. First, alarm rationalisation: every alarm tag justified through documented answers to the three questions "does this need human action, who takes that action, what action specifically." Second, state-based suppression during known upset conditions (startup, shutdown, changeover) where an alarm flood would otherwise be the mechanically predictable consequence of a normal operating mode. Third, root-cause bundling: when one master alarm triggers fifteen downstream consequential alarms, the MES should surface the master and suppress the consequentials. A plant starting from an unrationalised baseline typically sees alarm rates fall by 80–95 % through the first rationalisation exercise alone, without changing the underlying capture mechanism at all — most alarm flood is about what you surface, not about what the machine generates.

What is a chattering alarm and how do I fix it?
A chattering alarm is one that transitions between normal and active states three or more times within a 60-second window. It is almost always caused by a measured process variable oscillating around its alarm threshold without real change in process state — a temperature sensor at 78.5 °C when the alarm threshold is 78.0 °C, a flow rate fluctuating around its low-flow cutoff. The three fixes are time delay (require the condition to persist for 2–10 seconds before the alarm fires), deadband (set the return-to-normal threshold 2–5% below the alarm threshold so the alarm does not immediately re-fire), and hysteresis (a combination for continuous analog signals). Chattering alarms should be eliminated entirely; any chattering population above about 1% of alarm tags indicates a systematic configuration problem that warrants a rationalisation exercise rather than incremental patching.

How do I connect alarms from an old machine without OPC UA?
Three options in descending order of quality. If the machine has an S7-200/300/400 PLC without OPC UA, a direct-read connection via S7 protocol to the fault-bit data blocks works reliably — requires coordination with the controls engineer to document which bits carry which meaning, but otherwise produces clean boolean events. If the PLC is inaccessible or pre-dates S7 (Simatic S5, or equivalent from other vendors), a digital I/O gateway connected to the machine's hardwired 24 V status outputs captures the boolean transitions without any PLC contact. If the machine has neither accessible PLC nor hardwired status outputs, counter-derived synthetic alarms work as the fallback — a cycle counter that stops for more than 120 seconds is a synthetic fault even if the machine itself is not reporting the condition. All three approaches have been standard brownfield techniques in my projects for thirty-plus years; the choice is about what the machine is willing to say, not about what would be theoretically ideal. The MES normalises the output into a uniform event model regardless of the capture mechanism.

How does MES alarm management relate to Andon?
Andon is the physical visual/acoustic signalling layer on the shopfloor, originally from Toyota Production System, used to communicate machine state to humans in the immediate vicinity. MES alarm management is the systems-level event-correlation and escalation layer that operates at ISA-95 Level 3 with business context. The two are complementary, not competing: Andon communicates to the humans near the line, the MES communicates to the humans responsible for the line who may be elsewhere in the plant or off-shift. The integration point is that Andon state (tower light colour, board message) should feed into the MES as both an escalation input (light red = alarm active, start the workflow) and an escalation suppression input (supervisor physically present at the line = do not escalate further to plant management). A system that treats Andon as a parallel disconnected layer produces duplicate escalations and missed events; a system that integrates them produces the cleanest signal-to-noise ratio I have seen in discrete manufacturing.

What is the alarm-to-stoppage attribution rate?
The percentage of machine stoppages over 60 seconds that have at least one correlated alarm event in the MES alarm log within a 2-minute window around the stoppage. It is the KPI that directly measures how well your alarm capture reflects the actual downtime of the plant: a stoppage with no correlated alarm is invisible downtime, which is also unimprovable downtime because nobody can fix what nobody can see. Modern fully instrumented lines typically run 75–90% attribution; brownfield-instrumented plants typically run 30–55%. Improving attribution rate from the brownfield baseline toward the modern baseline is usually the highest-ROI alarm-management investment a plant can make, because every percentage point turns invisible downtime into explainable downtime that can be attacked with root-cause analysis and process improvement.

Related: MES: definition, functions & benefits · OEE: definition, calculation & practice · MES software compared · OEE software · Process documentation · Predictive quality · Change control · Role-based access control · Schedule adherence · On-Time Delivery · Rolled Throughput Yield · Scrap rate vs. rework rate · Recipe management · Alarms module · Process data module · Production metrics module · Automotive · Metal processing · Food & beverage · Plastics processing · For maintenance managers · For production managers · For operational excellence. External references: ISA-18 Alarm Systems Management committee (ISA-18.2 / IEC 62682) · EEMUA Publication 191 · OPC Foundation — OPC UA (Part 9: Alarms & Conditions).

About the author

Martin Brandel

MES Consultant and project lead at SYMESTIC since 2019. Over thirty years of industrial automation experience, from Simatic S5 and COROS SCADA in the early 1990s through OPC UA, MQTT Sparkplug B and IoT-gateway architectures today. Dipl.-Ing. Nachrichtentechnik. Career: automation engineer at Ing. Büro Jürgen Albert (1991–1995, warehouse management, material-flow and machine control with Simatic S5; COROS-based plant-wide visualisation); Hermos AG (1995–2000, commissioning of conveyor systems, process plants and paint lines on large projects in Eastern Europe and China); ODEVIS GmbH (later SYMESTIC, 2000–2018, Head of Automation Technology — built and led the department for eleven years, developed the software standard for process plants in the beverage and wood industries, led S5-to-S7/TIA retrofit projects that form the basis of SYMESTIC's machine-connectivity approach today). Expertise: machine data acquisition (MDE), operating data acquisition (BDE), PLC programming (Simatic S5, S7, TIA Portal), retrofit, OPC UA (Data Access and Alarms & Conditions profiles), MQTT Sparkplug B, IoT-gateway integration, brownfield machine connectivity, process control systems, material-flow control, industrial automation, MES project management, ISA-18.2 alarm rationalisation, EEMUA 191 benchmarking, Andon integration, CE conformity. · LinkedIn