A critical event in a power plant cannot wait for the next control-room round. When a boiler feed pump bearing crosses its alarm threshold at 2:30 AM, the shift supervisor needs to know before it becomes a unit trip — not when the day-shift maintenance manager reads the overnight log. But routing every alarm to every mobile is worse than routing none, because alarm floods desensitize the operators you actually need to trust the alert next time. Mobile alerting done right is a tiered discipline: critical events reach the right person on the right channel inside seconds, informational events digest by shift, and nuisance chatter stays out of the phone entirely.
iFactory / Power plant mobile alerts
The Right Alert, the Right Person, the Right Channel — Every Time
A tiered mobile alerting system that routes critical events by push and voice call to on-call operators, high-priority events by SMS and push to the shift supervisor, informational events to shift-end digest, and suppresses the nuisance chatter that erodes trust.
CRITICAL
Trip risk · immediate action
Call + push
HIGH
Excursion · attention now
Push + SMS
INFO
Status change · next round
Email digest
SUPPRESS
Nuisance · known chatter
DCS only
4 tiers
critical · high · info · suppress
Seconds
from event to notified operator
The Problem in the Control Room
A power plant control room has three ways alerts fail today. Either the DCS alarm sits on the screen unattended because the operator is on a round or handling another alarm — and the event escalates before anyone responds. Or every threshold and every setpoint fires a notification to every phone in the plant — and within a week the on-call engineer is muting the app because signal-to-noise has collapsed. Or the routing is done by email chain that nobody reads on nights and weekends. The result in all three cases is the same: the event that should have been caught at 2:30 AM becomes the trip at 4:15 AM, and the post-event review asks why nobody responded.
Where the Record Actually Breaks
Alert-routing gaps look predictable. Almost every plant has each of these failure modes somewhere in the current setup.
DCS-only alarms
Critical events fire only on the DCS. If the operator is on a round, in the switchyard, or handling another alarm, the event waits — until it escalates.
Everyone-gets-everything
Well-intended notification sprawl. Every setpoint change and every info-level alert fires to every subscribed phone. Within weeks, everyone mutes the app.
Email chains at night
Off-hours alerts routed by email. Nobody reads them until morning. The event that needed a 2 AM response gets seen at 7 AM with the post-mortem already required.
On-call rotation stale
Alerts go to a hardcoded distribution list that doesn't reflect this week's on-call rotation. The right person isn't notified; someone else on the list has to relay the call.
What Good Looks Like at the Desk
A working mobile alert system holds four disciplines together — tiered severity, channel routing per tier, rotation-aware recipient logic, and acknowledgment tracking with escalation on no-response.
Severity Classification
Every alert classified as critical (trip risk, safety, environmental), high (excursion needing attention), info (status change, next-round detail), or suppress (nuisance, known chatter).
4 tiers, defined
Channel by Tier
Critical routes to push + voice call. High to SMS + push. Info to shift-end digest. Suppress stays on the DCS. Each tier has its own escalation chain.
Channel matches urgency
Rotation-Aware Routing
Alerts route to the current on-call rotation for the affected system — not to a static distribution list. The right person gets the alert without a relay call.
Live rotation
Escalation on No-Response
Critical alerts unacknowledged in the target window auto-escalate to the shift supervisor, then to the plant manager — no event sits unanswered because one phone was on silent.
No orphan events
How iFactory AI Fits
iFactory AI overlays your DCS, historian, and on-call scheduling — Ovation, DeltaV, ABB 800xA, PagerDuty, ServiceNow — and adds the tiered routing layer that turns raw alarms into actionable notifications.
Alert Router
Notification Layer
Rules engine that classifies every incoming event by severity and routes to the appropriate channel and recipient set based on time, system, and rotation.
On-Call Registry
Overlay + HRIS
Live on-call rotation per system per shift, integrated with your existing scheduling tool so rotation changes propagate automatically.
Acknowledgment Log
Notification Layer
Every alert acknowledged with user, time, and channel — the record that answers 'who was notified and when' at post-event review.
Escalation Trail
Notification + Ops
Every escalation path with target window, recipients at each level, and final acknowledgment — the record that closes the loop on no-response events.
Ask your on-call engineer whether they have the alert app installed and whether notifications are turned on. If either answer is no, the system is not routing anything — and the next off-hours event will find that out for you. Book a demo — we'll audit one week of your alert routing live.
12-Week Rollout on One Unit
One unit, one on-call rotation, twelve weeks. The pilot is scoped to prove the alert flood is manageable, the critical events reach the right person in seconds, and the trust returns to the notification channel.
Weeks 1–2
Alarm Audit
Pull the last month of DCS alarms. Classify by frequency, severity, and current response pattern. Identify the top 20 nuisance alarms consuming attention.
Weeks 3–4
Tier Configuration
Configure severity tiers, channel routing per tier, and initial rotation logic. Nuisance alarms explicitly suppressed. Operators walk through with a mock event scenario.
Weeks 5–8
Live on One Unit
Mobile alerts active for the pilot unit. First week is calibration — false positives adjusted, missing routings added. On-call rotation integrated by week 2.
Weeks 9–12
Response Metrics
Twelve-week window closes. Measure acknowledgment time, escalation rate, and operator-reported alert quality. Rollout scope decided based on the response numbers.
Who Owns the KPI
Mobile alerting crosses operations, maintenance, on-call engineering, and plant leadership. Each function needs a number they own or the discipline reverts to alarm-fatigue paralysis.
Shift Supervisor
Critical alert acknowledgment time
Owns the front-line response — how fast the on-call operator acknowledges a critical event. Under 60 seconds is the working target off-hours.
Control Room Ops
Nuisance alarm rate per hour
Owns the noise floor — the count of suppressed or reclassified alarms per hour. Rising trend means the tier rules need refresh.
On-Call Engineering
Escalation events per week
Owns the loop-close — how many events required escalation because the first-level responder didn't acknowledge. Zero is the goal; rising means rotation coverage gaps.
Plant Manager
Off-hours incidents caught before trip
Owns the outcome — the count of events caught by mobile alert before they became trips or excursions. The number that justifies the whole system.
FAQ
What stops this from becoming another notification spam?
The tier discipline. Every alert has to be classified into critical, high, info, or suppress at the moment the rule is written — not left as 'notify everyone.' The nuisance alarms that were creating 60% of the noise get moved to suppress on day one. The high-tier alerts route to shift-supervisor push + SMS instead of everyone's phone. And the info tier collapses into a shift-end digest instead of individual notifications. Most plants find alert volume drops 70-80% at pilot go-live, while the critical event capture rate goes up — because the surviving alerts are trusted.
How does the on-call rotation integration actually work?
Most plants already maintain an on-call rotation in a scheduling system — PagerDuty, ServiceNow, a shared calendar, or a spreadsheet. The alert router reads that schedule via API (or on a defined refresh cadence for static systems) and routes tier-appropriate alerts to whoever is currently on call for the affected system. When rotations change, the routing updates automatically — no manual distribution list edits. The record shows who was on call at the time of the event, which is what post-event review actually needs.
Book a demo to see the rotation integration live.
What about cybersecurity — does routing plant data to mobile create NERC CIP risk?
Handled correctly, no. The mobile alerting layer receives event metadata (equipment tag, severity, value, timestamp) — not real-time control data or credentials to the DCS. Push and SMS payloads are configured to name the event without exposing sensitive plant details that would violate CIP-011 information protection requirements. Voice-call escalation reads a pre-recorded severity + tag message, again without sensitive data. The specific controls (payload content, encryption, mobile device management) are scoped during implementation against your utility's CIP-002 asset classification.
Stop letting nuisance alarms hide the events that actually matter.
Design the Alert Tiers for One Unit Live
Bring one unit's DCS alarm history from last month and your current on-call rotation. We'll classify the alarms by tier live, design the channel routing per severity, and quantify the noise reduction you'd see on day one.
