BLUF: Treat predictive-maintenance model warnings as candidate alarms, not as automatic operator alarms. A model score becomes an alarm only after an operations-led rationalization has documented the abnormal condition, consequence, required response, response window, owner, priority, threshold and suppression logic. Then manage the resulting portfolio with alarm-rate, flood, standing-alert, chattering and bad-actor metrics. This adapts the ISA-18.2 / IEC 62682 alarm-management discipline to AI alerts; it does not claim that a model dashboard is ISA-18.2 compliant. The practical objective is a small number of timely, actionable warnings—not the maximum possible anomaly recall.
Why predictive maintenance recreates the classic alarm problem
An anomaly model can score every sensor window, asset and failure mode. That scalability is technically useful and operationally dangerous. Lowering a threshold increases sensitivity, but it also converts harmless transients, state changes, sensor defects and repeated observations of the same condition into notifications. If each score crossing creates a ticket or audible annunciation, the model has simply automated alarm proliferation.
A production predictive-maintenance architecture already needs sensor quality, asset context, model scoring, human review and CMMS execution. Alarm rationalization adds the missing contract between model output and human attention: which condition deserves interruption, what action is possible, and how much time the responder actually has.
The ISA18 committee describes its scope as terminology and practices for alarm-system definition, design, installation, operation, maintenance and modification over time. ISA’s public overview of the ISA-18 series places alarm philosophy, identification, rationalization, implementation, monitoring and change management in one lifecycle. EEMUA states that Publication 191 is aligned with ISA 18.2 and IEC 62682:2023 and is primarily concerned with alarm systems provided to people operating industrial processes. Those boundaries matter: the standards address human response systems, not model accuracy in isolation. Sources: ISA18 committee, ISA-18 series overview and EEMUA Publication 191.
Start with an AI-alert philosophy
Create a short extension to the site alarm philosophy for model-generated warnings. Define an AI alert as a notification to a named operational role about an abnormal equipment condition that requires a defined response within a defined time. Everything else is an event, diagnostic, trend, prompt or engineering observation. Do not route non-actionable model output through the same channel as alarms.
The philosophy should specify: covered assets and operating states; who may receive each class; required evidence; priority method; confidence and persistence rules; duplicate grouping; deadband and delay conventions; shelving and suppression authorities; model and threshold change control; audit retention; performance targets; and the boundary between advisory AI and safety/control functions. Keep AI recommendations outside direct PLC and SIS command paths, as detailed in the AI–OT safety and security boundary.
Rationalization record: one row per asset–failure-mode pair
Do not rationalize only a generic model type. A vibration anomaly on a critical compressor and the same score on a redundant ventilation fan have different consequences, response times and acceptable false-positive costs. Create a master AI-alert database keyed by asset, failure mode, operating state, model revision and alert rule revision.
Required fields: alert ID; asset and hierarchy; suspected failure mode; valid operating states; data-quality prerequisites; model and feature versions; score definition; threshold; persistence window; deadband or hysteresis; on-delay and off-delay; duplicate/episode key; cause; consequence if ignored; responder; corrective action; maximum response time; priority; escalation; suppression conditions; CMMS mapping; evidence shown to the responder; validation dataset; precision, recall and detection lead-time by regime; approver; review date; and change history.
The exida explanation provides a useful operational test: an alarm should target the operator, indicate an abnormal situation, and require a timely corrective response. Its rationalization definition also emphasizes settings, cause, consequence, corrective action and time to respond in a master alarm database. Apply that test before discussing model confidence. Source: exida alarm rationalization guidance.
Architecture and data flow: separate scores, alert episodes and alarms
SENSOR / PLC / historian → time alignment and quality gate → asset and operating-state join → feature pipeline → model score stream → episode builder → rationalization policy engine → evidence packet → role-based notification or CMMS → acknowledgement and maintenance outcome → labelled feedback store → threshold review / model retraining → controlled release.
The episode builder is essential. It turns hundreds of window-level score crossings into one stateful condition with first-seen, last-seen, peak score, persistence, affected sensors and current lifecycle state. The policy engine then applies asset criticality, operating mode, data-quality status, threshold, hysteresis, delays, suppression and deduplication. Only the surviving episode is eligible for operator notification.
Store event time and processing time separately. Join every notification to raw-window identifiers, feature version, model digest, threshold policy, asset state and notification outcome. Sensor drift can otherwise masquerade as mechanical degradation; the validation pattern in validating digital twins against live sensor drift shows how to separate measurement integrity from model disagreement.
Metric mapping: ISA-18.2 discipline for AI-generated alerts
Classic metric | Published reference value | AI-alert equivalent | Engineering action Steady-state alarm load | exida lists 1–2 alarms per 10 minutes | Actionable AI notifications per operator per 10 minutes, segmented by shift and operating mode | Rationalize or aggregate before lowering thresholds Alarm flood | exida lists no more than 10 alarms per 10 minutes and less than 1% of time in flood | More than 10 AI notifications per operator in any rolling 10-minute window; track percentage of covered time | Correlate episodes, apply state-based suppression, test upset replay Chattering/fleeting alarms | Target zero | Repeated open/close cycles for the same asset–failure-mode episode | Add score hysteresis, minimum on/off duration and data-quality checks Standing/stale alarms | exida lists fewer than 5 at one time | Open AI episodes without current evidence, action, owner or expiry | Expire, escalate, convert to planned work or remove notification status Bad actors | exida lists top ten contributing less than 5% | Share of all notifications generated by the ten noisiest asset–rule pairs | Weekly Pareto review; threshold retune, feature repair or retraining Priority distribution | exida lists an annunciated distribution of 5% high, 15% medium, 80% low | Distribution of model alerts by consequence and response time—not confidence | Re-rationalize inflated priority; confidence is evidence, not severity
These figures are reference benchmarks, not universal ML acceptance criteria. The PAS/ISA overview explicitly cautions that target metrics are approximate, depend on process type, operator skill, HMI, automation and environment, and that alarm rate alone does not prove acceptability. Establish site-specific goals in the philosophy and evaluate them per operating position. Sources: exida metric table and ISA lifecycle discussion.
Threshold tuning is a precision–recall–workload decision
For a binary warning rule, precision is true positives divided by all positive predictions; recall is true positives divided by all actual positives. Moving the score threshold traces a precision–recall trade-off, as documented by scikit-learn’s precision-recall curve API. But neither metric captures operator workload, detection lead time, repeated notifications or consequence.
Tune thresholds per asset class, failure mode and operating regime. Use event-level labels, not window labels: one bearing defect spanning 5,000 windows is one operational episode. Report episode precision, episode recall, median and p10 lead time, alerts per operating hour, percentage of time in flood, chattering cycles, standing duration and maintenance yield. Weight missed detections by consequence and false alerts by investigation cost; do not average away a critical asset class.
A threshold should not be changed merely to hit an alarm-rate target. Raising it may silence a noisy sensor while hiding a genuine failure. First determine whether the noise is caused by data quality, state segmentation, duplicated windows, missing hysteresis, model calibration or an invalid alarm definition. Threshold adjustment is one controlled remedy, not the default.
Deadbands, hysteresis and delays for volatile model scores
Use two thresholds for a stateful episode. Open when score ≥ T_on for N complete windows; remain open until score ≤ T_off for M windows, where T_off < T_on. The gap is the deadband or hysteresis. Add an on-delay to reject short spikes and an off-delay to prevent immediate re-annunciation after a temporary recovery. Choose windows in physical time and require minimum sample coverage so a data gap cannot satisfy persistence.
Example design, not a universal default: a bearing alert opens after three consecutive complete one-minute windows above an asset-specific T_on; it closes only after ten complete windows below T_off; planned startup suppresses the rule; one episode key groups all repeated crossings until closure. Replay both known failures and benign transitions to calibrate delays. Longer persistence reduces nuisance alerts but consumes detection lead time; wider hysteresis reduces chatter but can keep a stale episode open.
Bad-actor review: fix the portfolio before retraining everything
Every week, rank asset–rule pairs by notification count, open duration, chattering transitions and low-yield work orders. For each top contributor, inspect evidence windows and classify the cause: sensor defect; incorrect operating-state join; duplicated ingestion; threshold miscalibration; weak feature; model distribution shift; repeated notification of one episode; missing maintenance closure; or an alert that never required timely action.
Choose the smallest valid intervention. Repair the sensor or timestamp path before touching the model. Add state logic before retraining on incompatible regimes. Add episode deduplication before raising the threshold. Remove or downgrade non-actionable warnings. Retune against a labelled replay set when calibration is wrong. Retrain only when the score no longer separates relevant conditions after data and policy defects are ruled out.
Control-loop diagram: rationalization feeds model operations
1. Observe → collect scores, episodes, notifications, acknowledgements, inspections and confirmed failures. 2. Measure → compute per-shift load, flood time, chatter, standing episodes, top-ten share, episode precision/recall and lead time. 3. Diagnose → review bad actors with operations, maintenance, reliability and data engineering. 4. Select intervention → data repair, state logic, deduplication, deadband/delay, threshold retune, alert removal or model retraining. 5. Validate → replay stable, transition, known-fault and sensor-fault periods; compare candidate against current policy. 6. Approve → record rationale, owner and rollback; use management of change. 7. Canary → expose one asset group or shift, monitor workload and missed-event guardrails. 8. Sustain → audit the portfolio and feed confirmed outcomes into the next review.
Decision table: what should happen to a model signal?
Observed condition | Classification | Route | Main control High score, actionable failure hypothesis, named response and enough lead time | Candidate alarm | Rationalize, then notify approved role | Consequence/response-time priority plus evidence packet High score, no operator action possible | Diagnostic event | Engineering analytics, not alarm channel | Trend and review; do not interrupt operations Repeated score oscillation around threshold | Chattering episode | Hold one stateful episode | Hysteresis and on/off delays Many assets fire during startup or changeover | Context mismatch / flood | Suppress by designed state, retain event evidence | Verified operating-mode signal and replay test Long-lived open episode with accepted work order | Standing maintenance condition | CMMS state, limited reminder/escalation | Owner, due date and expiry Data quality invalid or sensor stale | Data-quality incident | Quarantine model result; investigate instrumentation | Quality gate before model score becomes eligible Safety-critical condition already covered by SIS/BPCS alarm | Possible duplicate | Preserve validated safety path; AI may add evidence only | Safety engineering review; no AI replacement claim
Failure modes that survive a polished dashboard
1. Window inflation. One physical condition creates thousands of positives and makes model recall look excellent while overwhelming humans. Evaluate episodes. 2. Confidence becomes priority. A score of 0.99 says nothing about consequence or response time. Prioritize through risk and operations. 3. Alert-rate optimization hides failures. Teams raise thresholds until the chart is green. Protect recall and lead-time floors for consequential classes. 4. Suppression has no audit trail. A maintenance engineer silences a bad actor indefinitely. Time-bound suppression, owner, reason and expiry are mandatory controls. 5. Model retraining treats sensor faults as truth. Quarantine invalid measurements and preserve calibration evidence. 6. Startup floods. A model trained on steady state sees every transition as abnormal. Segment operating modes and test upset behavior. 7. CMMS feedback is ambiguous. “Closed” may mean no fault found, deferred work or replaced component. Use structured outcome codes and retain notes. 8. Notification routing is mistaken for rationalization. Sending alerts faster does not make them necessary or actionable.
Trade-offs and limitations
ISA-18.2 and IEC 62682 were designed for process-industry alarm systems; applying their lifecycle and metrics to predictive-maintenance model warnings is an engineering adaptation. It does not turn every maintenance notification into a process alarm, provide universal thresholds, validate an ML model, or prove regulatory conformity. EEMUA likewise notes that its guidance is primarily for people operating industrial processes, although elements can be interpreted for other sectors.
Lower alert volume can improve attention but may reduce recall or shorten warning lead time. Persistence and hysteresis add stability but delay notification. Per-asset rules improve relevance but increase configuration and change-management cost. Bad-actor review gives quick wins but can neglect rare high-consequence failure modes. Adaptive thresholds may follow operating regimes, yet they are harder to validate, explain and rollback.
Whether a site is legally required to follow a specific standard, whether an alert can claim a protection-layer role, and how a change affects process-safety obligations require competent safety and legal review. Engineering can provide the versioned evidence, tests, approvals and audit trail; it should not make the legal conclusion.
Implementation checklist
Week 1 — Baseline: inventory every model-to-human notification; identify recipients and operating positions; calculate rolling 10-minute rates, flood time, chattering, standing episodes and top-ten contributors; sample 30 high-volume episodes for actionability. Week 2 — Philosophy and rationalization: define alarm versus event; choose priority and evidence rules; rationalize the highest-volume asset–failure-mode pairs; document cause, consequence, action and response time. Week 3 — State layer: implement episode keys, T_on/T_off hysteresis, delays, data-quality eligibility, operating-mode suppression, expiry and CMMS linkage. Week 4 — Replay and canary: replay stable, startup, known-fault and sensor-fault periods; compare workload, event precision/recall and lead time; canary on a bounded asset group; approve or rollback through change control. Ongoing — Sustain: weekly bad-actor review, monthly metric review, post-maintenance threshold checks, and forced revalidation after model, feature, sensor, state logic or asset-criticality changes.
Authoritative sources and interpretation boundary
References used: ISA18 committee scope; ISA-18 standards and technical-report overview; ISA alarm-management lifecycle discussion; EEMUA Publication 191 Fourth Edition overview; exida rationalization criteria and performance metrics; and SeQent’s alarm-rationalization overview. The numeric performance table is reported as a published reference benchmark and must be adapted to the site, operator position and process. This article does not reproduce or replace the standards.
Turn model alerts into an operator contract
If your predictive-maintenance pilot detects anomalies but maintenance teams no longer trust the notifications, I can help map the score stream, rationalize the highest-volume asset rules, design the episode and suppression layer, and build a replay evaluation with workload and missed-failure guardrails. The useful deliverable is not a quieter dashboard. It is a versioned contract that states which condition interrupts whom, why, with what evidence, and how the rule is changed safely.
